Intent to Ship: Streaming declarative shadow DOM

Mason Freed

unread,

Jan 19, 2023, 7:36:50 PM1/19/23

to blink-dev

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

declarative, shadow

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
declarative, shadow

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?

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

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:

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?

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.

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

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

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9pyLc1B%3Dnqu1KU3pAWnQWPcM5Ankd34p0jA7AuBWmETg%40mail.gmail.com.

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUyHD0u3jfXGT8-9gJ7Srapg3eEr%3DBo3hBAnGS8HQ8rPg%40mail.gmail.com.

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