Intent to Implement: rendersubtree attribute.

174 views
Skip to first unread message

Vladimir Levin

unread,
Sep 13, 2019, 11:52:03 AM9/13/19
to blink-dev

Contact emails

chri...@chromium.org, rak...@chromium.org, vmp...@chromium.org 


Explainer

https://github.com/WICG/display-locking/blob/master/README.md

https://github.com/whatwg/html/issues/4861


Note that rendersubtree is the latest iteration in design of display locking, and it replaces the imperative methods referenced in the display locking intent to implement (https://groups.google.com/a/chromium.org/d/msg/blink-dev/2Yo590-USNo/7Da9scWwBwAJ)


Summary

The rendersubtree attribute allows the developer to inform the browser that rendering may be skipped in the subtree of the element. The values of rendersubtree attribute are space separated tokens that indicate the desired behavior.

  • “invisible”: indicates that the content of the subtree should not be drawn to screen, or hit-tested. 

  • “activatable”: indicates that the browser can replace the value of rendersubtree with an empty string. This happens in specified situations where it is desirable to draw the content (e.g. find-in-page locates an entry in the rendersubtree=”invisible activatable” subtree, https://github.com/WICG/display-locking#element-activation-by-the-user-agent)


Note that the presence of the rendersubtree attribute forces layout and style containment.


Motivation

The rendersubtree attribute provides a strong hint to the browser that content under the element is not going to affect the page outside of the element (due to containment), and that it is not visible or hit-testable (if “invisible” token is present). This affords the browser an opportunity to skip work in the subtree of the element. Specifically, it is possible to skip style, layout, and paint. In turn, this lends more time to the browser to perform work in other parts of the page, improving the overall performance of the site.


Risks

Interoperability and Compatibility

This is a new feature so the risk of breaking existing content is low. See Activation section below for possible polyfills.


Edge: Positive (in person discussions)

Firefox: No Signals (note that initial display-locking proposal had negative signals (https://github.com/mozilla/standards-positions/issues/135), but we believe we’ve addressed the feedback in the design of rendersubtree)

Safari: No Signals (similar situation to Firefox: negative signals for the initial display-locking proposal, but we believe we’ve addressed the issues).

Web / Framework developers: Interest from ReactJS and AMP.


Ergonomics

This feature can be used independently to provide rendering savings on pages that use it correctly. It works well with content-size CSS property, which can provide a placeholder size when rendersubtree “invisible” token is present.


Activation

This feature can be used directly with minimal effort. If the feature is not present, it can be polyfilled by making the content invisible by other means (visibility or display: none), which does not have an equivalent to the “activatable” token and may not provide a strong enough guarantee for browsers to skip rendering work. Alternatively, it can be “polyfilled” by simply leaving content as-is which can incur extra rendering cost, but remains searchable.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/4613920211861504


Requesting approval to ship?

No


Vladimir Levin

unread,
Oct 10, 2019, 3:39:05 PM10/10/19
to blink-dev
TAG review: https://github.com/w3ctag/design-reviews/issues/306#issuecomment-530171862 (comment explaining rendersubtree under the display locking review request)
Reply all
Reply to author
Forward
0 new messages