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
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.
No difference from existing, shipped declarative shadow DOM implementation.
No difference from existing, shipped declarative shadow DOM implementation.
No difference from existing, shipped declarative shadow DOM implementation.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No difference from existing, shipped declarative shadow DOM implementation.
M111
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).
Contact emails
mas...@chromium.orgExplainer
https://github.com/whatwg/html/pull/5465
https://github.com/whatwg/dom/pull/892Specification
https://github.com/whatwg/html/pull/5465Summary
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>ShadowDOMSearch tags
declarative, shadowTAG review
TAG review status
Not applicableRisks
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)?
YesIs this feature fully tested by web-platform-tests?
Yes
Flag name
StreamingDeclarativeShadowDOMRequires code in //chrome?
FalseTracking bug
https://crbug.com/1379513Estimated 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/5161240576393216This 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.
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.
Is this feature fully tested by web-platform-tests?
YesI 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?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9pyLc1B%3Dnqu1KU3pAWnQWPcM5Ankd34p0jA7AuBWmETg%40mail.gmail.com.
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.