Intent to Prototype: renderpriority attribute

[Vladimir Levin]

Contact emails

vmp...@chromium.org

Explainer

https://github.com/WICG/display-locking/blob/main/explainers/update-rendering.md

Summary

The web includes a number of features and heuristics (such as content-visibility, containment and others) that allow the User Agent to skip rendering work for elements and contents of elements that are not visible to the user. This is done with the intent to allow other content, animations and interactions to remain smooth and get as much CPU time as possible. However, there are situations where this neglects the site intent of showing currently skipped content shortly. In other words, if the website intends to show an element whose contents are currently skipped, then skipping work may cause jank when the contents are ultimately presented.

The renderpriority attribute is an HTML attribute that informs the User Agent to keep the element's rendering state updated with a specified priority.

Blink component

Blink>Paint

TAG review

https://github.com/w3ctag/design-reviews/issues/676

TAG review status

Pending

Risks

This is a new performance feature that allows the User Agent to break up the rendering work over several frames. It has minimal risk. We need to ensure that we consider timing as a potential attack, but I think that can be mitigated.

Interoperability and Compatibility

Since this is a new feature that does not affect anything other than the timing of the rendering work, there is no risk to interoperability and compatibility: User Agents that don't support the feature would essentially treat the rendering work as synchronous when it is presented. This is no different from what happens today. User Agents that do support the feature would be able to make iterative progress on the rendering work, thus having a shorter delay when the content is ultimately presented.

Gecko: No signal

WebKit: No signal

Web developers: Positive (partner feedback in email -- I'll work on getting public signals)

Debuggability

Is this feature fully tested by web-platform-tests?

No. I will add tests, although being a performance primitive this may be difficult to test.

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1251363

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5764311403200512

[Yoav Weiss]

Thanks for working on this! It may be interesting to think through if/how this interacts with other prioritization work (on the network or on the script scheduling side). Adding Pat and Scott for visibility.