Intent to Extend Origin Trial: Declarative Shadow DOM

128 views

Skip to first unread message

Mason Freed

unread,

Oct 2, 2020, 6:18:14 PM10/2/20

to blink-dev

{I used chromestatus.com to generate this email, but it looks like a full Intent to Experiment. I've tried to fix it up as appropriate. This is meant to be an extension - the prior approval was for M85-87, and this asks to extend to M88.}

Contact emails

mason...@chromium.org

Explainer

https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md

Specification

None

Design docs

https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md
https://github.com/whatwg/dom/pull/858
https://github.com/whatwg/html/pull/5465

Summary

A declarative API to allow the creation of #shadowroot's using only HTML and no Javascript. Sign up for an Origin Trial (M85-M88) here: https://developers.chrome.com/origintrials/#/register_trial/2024368032503037953 Blog post: https://web.dev/declarative-shadow-dom/

TAG review status

Issues addressed (?)

Risks

Interoperability and Compatibility

The main interoperability risk would be that other browsers fail to implement this API. This feature is roughly polyfillable, so it should still be usable while other implementations are being completed.

Gecko: Some conversation, no conclusions

WebKit: Some comments, no conclusions

Web developers: Positive See many comments from developers on the prior thread resolving *not* to move forward with declarative Shadow DOM. Most are positive and want a solution to this problem. Start after this comment: https://github.com/whatwg/dom/issues/510#issuecomment-370980398

Ergonomics

Much thought has been given to the ergonomics of this API. A more ergonomic alternative, that of a new <shadowroot> element, would create significant web compat problems for browsers that do not yet support the new element. The biggest risk of the current proposal is that it does not *also* solve the declarative adoptedStylesheets problem. That is, to include stylesheets within declarative shadowroots, inline <style> elements must be used. That isn't as large of a penalty as it would seem, but it is a stumbling block. See https://github.com/whatwg/dom/issues/831#issuecomment-585451735, point #3 for more discussion of this issue.

Activation

This feature is rather polyfillable - see https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#feature-detection-and-polyfilling. However, any such polyfill would require Javascript to work, and the prime motivation for this feature is no-JS SSR. However, for sites that want to use Web Components and Shadow DOM, it would seem that such a polyfill could be written in a way that does not impact performance for browsers that have implemented this proposal, and does no worse for browsers that have not yet supported this API.

Security

The prior implementation of <template> caused significant parser security issues. While this proposal attempts to re-use as much as possible of the existing <template> implementation, there are a few required changes. It is possible that those changes introduce new security holes. Additionally, the existing implementation of <template> could also still contain undiscovered security problems.

Goals for experimentation

- Ergonomics of the API, etc. - Common use cases. In particular, I'm curious how often the Shadow DOM content for a given Custom Element is identically the same across a page, vs. slightly different from instance to instance. - Speed, bugs, etc.

Experimental timeline

M85-M88

Reason this experiment is being extended

Origin trial partners are taking longer than expected getting up and running, due to other external priorities and circumstances. They are expected to start very soon, but we need at least another milestone. Prior I2E thread: https://groups.google.com/a/chromium.org/d/msg/blink-dev/DuvhXyYo7Pc/_zcDVQmCAAAJ

Ongoing technical constraints

None

Debuggability

Since this is a parser-only feature, parsed DOM content will contain only "normal" #shadowroot nodes. Devtools already fully supports Shadow DOM, and all of those existing tools will continue to apply to this new method of declaratively creating Shadow DOM.

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

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

Yes: https://wpt.fyi/results/shadow-dom/declarative?label=master&label=experimental&aligned&q=declarative%2F

Tracking bug

https://crbug.com/1042130

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5191745052606464

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msg/blink-dev/nJDc-1s3R9U/uCJKsEqpAwAJ
Intent to Experiment: https://groups.google.com/a/chromium.org/d/msg/blink-dev/DuvhXyYo7Pc/_zcDVQmCAAAJ

This intent message was generated by Chrome Platform Status.

Chris Harrelson