Re: [w3ctag/design-reviews] renderPriority element attribute (#676)

Thank you for you feedback and questions!

> Will there be a way to set a default for this, say for a custom element?

We don't have plans to expose a way to set a default behaviour. One of the alternatives that @andruud suggested is to use a CSS property instead of an Element attribute. This would allow you to target more than one element, effectively setting a default behaviour. As the [issue](https://github.com/WICG/display-locking/issues/200#issuecomment-926450085) talks about, I'd like to get TAG guidance on whether the attribute or property is more appropriate here.

> How does this work with nesting? E.g. if I have an ancestor with `renderpriority="background"` and a descendant with `renderpriority="user-blocking"`, doesn't that effectively cancel the ancestor's `renderpriority`, since the ancestor would need to be rendered to render the descendant?

> Wouldn't that also enable advertisers from just injecting HTML with `renderpriority="user-blocking"` to hog resources for their ads?

I've had some thoughts on a similar case here: https://github.com/WICG/display-locking/issues/200#issuecomment-919645611
I agree that upgrading the renderpriority to something higher in the subtree is problematic, since it would violate the ancestor render priority setting and cause more work than necessary (as you mention with the ads injecting high priority content). I believe there is no such issues if we keep the priority at the minimum of ancestor and nested element (i.e. if one of them is background, then the content in the inner element is updated with background priority). We are also considering not updating nested renderpriority things at all (ie treat them as renderpriority=never), which would simplify reasoning about this and allow us to have improvements in the future.

> I would also have liked a discussion on what kind of performance gain would this enable, for a sufficiently complex DOM (e.g. the HTML spec). Are we increasing the complexity of the web platform to save some nanoseconds or is it a more significant gain?

I can add a section to the explainer to try and foster such a discussion. Just from dealing with content-visibility content, I can say that it saves anywhere on the order from milliseconds to [seconds](https://twitter.com/b56girard/status/1417918695792201732) of load time. The way this is set up though is that the work is deferred until it is needed. With appropriately chunked content, `content-visibility: auto` would naturally do this as the user scrolls, updating small pieces at a time as they enter the viewport. In the Single-Page App example that I alluded to, however, this means that whatever work you may save will still need to happen when the content is displayed to the user (and it would happen synchronously).

With this proposed feature, the developer can set `renderpriority=background` on the element which will ultimately be presented to the user. This will allow the user-agent to start doing work in that subtree without displaying the content, but preparing things like style and layout values. When the content is ultimately presented, the work that was initially deferred would have already been completed, so the content is displayed faster. So the savings here largely depend on the complexity of the content displayed and the amount of time the user-agent had to update this with background priority.

> How would an author use `renderpriority` to enable this use case? What value would they use? Are they supposed to change the value before navigation?

The developer would display the content (i.e. removing `content-visibility: hidden`). Changing the `renderpriority` value is something that they can do optionally as well, but I don't think it's a necessity to get the performance. 



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/676#issuecomment-942487860