Intent to Ship: Streaming declarative shadow DOM

668 views
Skip to first unread message

Mason Freed

unread,
Jan 19, 2023, 7:36:50 PM1/19/23
to blink-dev

Contact emails

mas...@chromium.org

Explainer

https://github.com/whatwg/html/pull/5465
https://github.com/whatwg/dom/pull/892

Specification

https://github.com/whatwg/html/pull/5465

Summary

Chromium has shipped [1] a version of declarative shadow DOM in M90 which currently has 0.014% usage [2]. Mostly, the low usage is due to the spec PR being stalled with no input from other implementers. Recently, there has been renewed interest in the feature, and discussions have resumed. As part of those discussions, two changes have been generally agreed upon: 1. Rename the `<template>` attribute from `shadowroot` to `shadowrootmode`. 2. Support streaming, by attaching the shadow root on the opening, rather than the closing, template tag. While the PR hasn't landed, and there is still an open issue (related to the DOMParser), we would like to ship the agreed upon behavior listed above. WebKit has already enabled this behavior by default. [1] https://chromestatus.com/feature/5191745052606464 [2] https://chromestatus.com/metrics/feature/timeline/popularity/3196



Blink component

Blink>DOM>ShadowDOM

Search tags

declarativeshadow

TAG review



TAG review status

Not applicable

Risks



Interoperability and Compatibility

The new version of declarative shadow DOM has observable differences in behavior: streaming. The launch plan is to ship the new behavior via the new attribute name (`shadowrootmode`), while preserving the old behavior under the old attribute name (`shadowroot`). Once the new behavior is landed and stabilized, we will make a plan to deprecate the old shadowroot attribute and behavior. This should ensure that the compat risk is low as we transition to the new behavior.



Gecko: Positive (https://github.com/whatwg/html/pull/5465#pullrequestreview-1132523065)

WebKit: Positive (https://github.com/whatwg/html/pull/5465#pullrequestreview-1132523065)

Web developers: Positive (https://github.com/whatwg/dom/issues/831) Search "streaming" on the issue discussion and you'll find many supportive comments.

Other signals:

Ergonomics

No difference from existing, shipped declarative shadow DOM implementation.



Activation

No difference from existing, shipped declarative shadow DOM implementation.



Security

No difference from existing, shipped declarative shadow DOM implementation.



WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?



Debuggability

No difference from existing, shipped declarative shadow DOM implementation.



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

Yes

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

Yes

Flag name

StreamingDeclarativeShadowDOM

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1379513

Estimated milestones

M111



Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5161240576393216

This intent message was generated by Chrome Platform Status.

Rick Byers

unread,
Jan 24, 2023, 11:41:23 AM1/24/23
to Mason Freed, blink-dev
Hi Mason,
Thanks for continuing to work to get interoperable support for declarative shadow DOM! 

On Thu, Jan 19, 2023 at 7:36 PM Mason Freed <mas...@chromium.org> wrote:

Contact emails

mas...@chromium.org

Explainer

https://github.com/whatwg/html/pull/5465
https://github.com/whatwg/dom/pull/892

Specification

https://github.com/whatwg/html/pull/5465

Summary

Chromium has shipped [1] a version of declarative shadow DOM in M90 which currently has 0.014% usage [2]. Mostly, the low usage is due to the spec PR being stalled with no input from other implementers. Recently, there has been renewed interest in the feature, and discussions have resumed. As part of those discussions, two changes have been generally agreed upon: 1. Rename the `<template>` attribute from `shadowroot` to `shadowrootmode`. 2. Support streaming, by attaching the shadow root on the opening, rather than the closing, template tag. While the PR hasn't landed, and there is still an open issue (related to the DOMParser), we would like to ship the agreed upon behavior listed above. WebKit has already enabled this behavior by default. [1] https://chromestatus.com/feature/5191745052606464 [2] https://chromestatus.com/metrics/feature/timeline/popularity/3196



Blink component

Blink>DOM>ShadowDOM

Search tags

declarativeshadow

TAG review

TAG review status

Not applicable

Risks



Interoperability and Compatibility

The new version of declarative shadow DOM has observable differences in behavior: streaming. The launch plan is to ship the new behavior via the new attribute name (`shadowrootmode`), while preserving the old behavior under the old attribute name (`shadowroot`). Once the new behavior is landed and stabilized, we will make a plan to deprecate the old shadowroot attribute and behavior. This should ensure that the compat risk is low as we transition to the new behavior.



Gecko: Positive (https://github.com/whatwg/html/pull/5465#pullrequestreview-1132523065)

Per our process, Mozilla has asked that we only consider positive signals from their standards-position repo. I see they currently have a 'neutral' for declarative shadow DOM with concerns about the cost/benefit tradeoff of the feature. 

Also this is a link to a comment by a (now) Apple employee. Did you have a different link in mind perhaps?


Based on your link above we can now call this "shipping", right? That's a very strong signal IMHO.

Web developers: Positive (https://github.com/whatwg/dom/issues/831) Search "streaming" on the issue discussion and you'll find many supportive comments.

Other signals:

Ergonomics

No difference from existing, shipped declarative shadow DOM implementation.



Activation

No difference from existing, shipped declarative shadow DOM implementation.



Security

No difference from existing, shipped declarative shadow DOM implementation.



WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?



Debuggability

No difference from existing, shipped declarative shadow DOM implementation.



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

Yes

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

Yes

I see the test link, but are tests written somewhere for this change in particular? In particular do latest WebKit and chromium with this flag enabled pass the exact same set of tests for declarative shadow DOM or are there still notable behavior differences?

Flag name

StreamingDeclarativeShadowDOM

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1379513

Estimated milestones

M111



Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5161240576393216

This intent message was generated by Chrome Platform Status.

--
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/CAM%3DNeDhGHqD6du83UKvRpX-P7ftaG_R8j1pXE-ofqwHGf-sysA%40mail.gmail.com.

Mason Freed

unread,
Jan 24, 2023, 2:59:10 PM1/24/23
to Rick Byers, blink-dev
On Tue, Jan 24, 2023 at 8:41 AM Rick Byers <rby...@chromium.org> wrote:

Per our process, Mozilla has asked that we only consider positive signals from their standards-position repo. I see they currently have a 'neutral' for declarative shadow DOM with concerns about the cost/benefit tradeoff of the feature. 

Also this is a link to a comment by a (now) Apple employee. Did you have a different link in mind perhaps?

Good catch - that was a link copy/paste mistake on my part. I've updated Chromestatus, but the link I was intending to use was this one for Mozilla. Having said that, it isn't obviously supportive, so I've also asked to have the position issue re-opened and hopefully updated.  
 

Based on your link above we can now call this "shipping", right? That's a very strong signal IMHO.

Thanks - also updated. It is indeed shipping, and WebKit's official position is now also "support".
 

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

Yes

I see the test link, but are tests written somewhere for this change in particular? In particular do latest WebKit and chromium with this flag enabled pass the exact same set of tests for declarative shadow DOM or are there still notable behavior differences?

So I've already updated the tests on WPT to use the new `shadowrootmode` attribute, and they also now check for streaming behavior. (For Chromium, I have a virtual suite that also tests the old behavior, which I'll keep running until I'm able to deprecate and remove it.)

WebKit (reportedly) passes all of those tests except the ones related to the serialization behavior which was pulled out of the current PR. There is still ongoing discussion around enabling imperative parsing (via DOMParser) of DSD content, and if they end up removing that functionality, they'll fail more tests.

Thanks,
Mason

Rick Byers

unread,
Jan 24, 2023, 3:27:18 PM1/24/23
to Mason Freed, blink-dev
Thanks Mason. LGTM1

Yoav Weiss

unread,
Jan 25, 2023, 2:34:18 AM1/25/23
to Rick Byers, Mason Freed, blink-dev

Philip Jägenstedt

unread,
Jan 25, 2023, 10:33:10 AM1/25/23
to Yoav Weiss, Rick Byers, Mason Freed, blink-dev
LGTM3, that this is already enabled in WebKit makes it a pretty simple case.

Mason Freed

unread,
Jan 25, 2023, 10:43:33 AM1/25/23
to Philip Jägenstedt, Rick Byers, Yoav Weiss, blink-dev
Thanks everyone!
Reply all
Reply to author
Forward
0 new messages