Contact emails
*vmp...@chromium.org <vmp...@chromium.org>*Explainer *https://github.com/WICG/display-locking/blob/main/explainers/update-rendering.md <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 <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPaint>*TAG review *https://github.com/w3ctag/design-reviews/issues/676 <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 <https://github.com/WICG/display-locking/issues/208> 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 signalWebKit: No signalWeb developers: Positive (partner feedback in email -- I'll work on getting public signals)*Debuggability Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> ? *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 <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 -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2MEt1kO%2BS0RM-G%2B6Jnf4NeVx2AHNrxXy_WvhPZpaoMTkQ%40mail.gmail.com.
