Intent to Experiment: rendersubtree attribute + CSS content-size

[Vladimir Levin]

Contact emails

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

Spec

rendersubtree: https://github.com/whatwg/html/pull/4862 (tracked via https://github.com/whatwg/html/issues/4861)

content-size: http://tabatkins.github.io/specs/css-content-size/

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.

 

CSS content-size is a feature that allows easier adoption of rendersubtree by supplying the developers the ability to specify placeholder size while rendersubtree=invisible is active.

 

Origin trial status document:

https://github.com/WICG/display-locking/blob/master/origin-trial-status.md

Explainer for both these features can be found here:

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

 

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/Bh0bSdkQlbk/7n6b50N6AwAJ

Goals for experimentation

The goals of the experiment are to gather feedback from developers in the form of the following:

• Feedback on ergonomics of use: Can the feature be used easily? Are there any unforeseen barriers that prevent easy adoption?

• Feedback on performance changes. Specifically, is there an observable performance benefit for load time and rendering update time when the attribute is specified?

The answers to these questions will help guide the final API shape of the feature, as well as provide metrics numbers which act as evidence for the performance benefits of the attribute.

Experimental timeline

Start: M79

End: M81

Any risks when the experiment finishes?

No

Ongoing technical constraints

None

Debuggability

Elements within a rendersubtree=invisible subtree, when inspected, will cause DevTools to highlight the ancestor with the attribute, as well as text informing the developer/user that what is shown is the locked ancestor.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes

Link to entry on the feature dashboard

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

[Alex Russell]

Hey Vlad,

The I2I doesn't appear to include the required TAG review request. Can you file one or provide a rationale for not sending it through that channel?

LGTM pending that.

Regards

[Vladimir Levin]

The tag review has been filed initially under display locking, here's a comment explaining the changes:

https://github.com/w3ctag/design-reviews/issues/306#issuecomment-530171862

I'll follow-up on I2I with this as well.

Thanks,

Vlad

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b25e45f5-31b4-4517-8b3a-9f00dab635d3%40chromium.org.