Intent to Prototype: *Streaming* declarative shadow DOM

311 views
Skip to first unread message

Mason Freed

unread,
Dec 6, 2022, 1:05:34 PM12/6/22
to blink-dev

Contact emails

mason...@google.com

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.002% usage [2]. Mostly, that 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 are being requested: 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. Chromium would like to prototype these changes. [1] https://chromestatus.com/feature/5191745052606464 [2] https://chromestatus.com/metrics/feature/timeline/popularity/3196



Blink component

Blink>DOM>ShadowDOM

Motivation

Developers have always wanted declarative shadow DOM to support streaming, but other implementers were always opposed to making the required changes to the HTML parser. Recently, those concerns were changed, and other implementations proceeded with a streaming prototype.



Initial public proposal



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. The plan for prototyping the new approach while keeping the functionality of the old approach is to trigger the new streaming behavior based on the presence of the new attribute `shadowrootmode`. If the (old) `shadowroot` attribute is used, the old non-streaming behavior will be used. This should ensure there are no compat risks, as we transition to the new behavior. Eventually, the plan would be to deprecate the old non-streaming behavior and `shadowroot` attribute.



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.



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

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5161240576393216

This intent message was generated by Chrome Platform Status.

Yoav Weiss

unread,
Dec 7, 2022, 1:24:20 AM12/7/22
to Mason Freed, blink-dev
Great news!! :)

--
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%3DNeDg1Aa7f5j3Kbqag_QwWYpLhAqwkDo0Sv1Xt5mtPCpmkBw%40mail.gmail.com.

Alex Russell

unread,
Dec 7, 2022, 8:33:58 PM12/7/22
to blink-dev, yoav...@chromium.org, blink-dev, mas...@chromium.org
+1; great news on the streaming front.

On the potential attribute name change, is it not possible to introduce streaming behaviour under the old name?

Best,

Alex

Mason Freed

unread,
Dec 7, 2022, 8:46:20 PM12/7/22
to Alex Russell, blink-dev, yoav...@chromium.org
On Wed, Dec 7, 2022 at 5:33 PM Alex Russell <sligh...@gmail.com> wrote:
+1; great news on the streaming front.

On the potential attribute name change, is it not possible to introduce streaming behaviour under the old name?

Thanks! Yes, it's totally possible to introduce streaming without changing the attribute name. But in the spec PR conversations, keeping the old name seems to be a non-starter. The issue is that the IDL reflection, `shadowRoot`, shadows (ha!) the Element.shadowRoot attribute, and causes some ambiguity. It's not a practical problem for developers, since HTMLTemplateElement.shadowRoot is always null and is relatively useless. But for consistency, the editors wanted a name change, to something that can just reflect the string values ("open" and "closed") directly.

Thanks,
Mason

Alex Russell

unread,
Dec 9, 2022, 2:28:36 AM12/9/22
to blink-dev, Mason Freed, blink-dev, Yoav Weiss, Alex Russell
In general, we should not agree to changes that are purely cosmetic after shipping, and spec PR conversations aren't a substitute for developer feedback.

I'm disinclined to suggest we ship a renamed feature for purely editorial reasons. Can we proceed to test under the old names to detect possible breakage?

Thanks,

Alex

Mason Freed

unread,
Dec 9, 2022, 12:31:22 PM12/9/22
to Alex Russell, blink-dev, Yoav Weiss, Alex Russell
On Thu, Dec 8, 2022 at 11:28 PM Alex Russell <sligh...@chromium.org> wrote:
In general, we should not agree to changes that are purely cosmetic after shipping, and spec PR conversations aren't a substitute for developer feedback.

I'm disinclined to suggest we ship a renamed feature for purely editorial reasons. Can we proceed to test under the old names to detect possible breakage?

I do see your point, and I wish we'd had these conversations (about naming and behavior) 2+ years ago when I tried very hard to engage with the other implementers. Having said that, one nice thing about the new name is that it gives a compat-guaranteed path to streaming. And of the two changes (streaming, and a new name), I think there is ample evidence that developers care a lot about streaming, and likely don't care what the attribute is called, other than typing 4 more characters. There will be some migration pain, for sure, but it's probably worth it for an interoperable standard and no compat risk.

Side-note: there is also an ongoing conversation (also here) over the developer need for a synchronous parsing entry point for DSD. I'm hopeful we'll reach consensus to keep this feature, interoperably. But if folks on this thread have compelling use cases for the ability to use DOMParser to parse DSD content, please comment here.

Thanks for the comments!

Mason

Alex Russell

unread,
Dec 9, 2022, 1:48:42 PM12/9/22
to blink-dev, Mason Freed, blink-dev, Yoav Weiss, Alex Russell, Alex Russell, Chris Wilson
On Friday, December 9, 2022 at 9:31:22 AM UTC-8 Mason Freed wrote:
On Thu, Dec 8, 2022 at 11:28 PM Alex Russell <sligh...@chromium.org> wrote:
In general, we should not agree to changes that are purely cosmetic after shipping, and spec PR conversations aren't a substitute for developer feedback.

I'm disinclined to suggest we ship a renamed feature for purely editorial reasons. Can we proceed to test under the old names to detect possible breakage?

I do see your point, and I wish we'd had these conversations (about naming and behavior) 2+ years ago when I tried very hard to engage with the other implementers. Having said that, one nice thing about the new name is that it gives a compat-guaranteed path to streaming. And of the two changes (streaming, and a new name), I think there is ample evidence that developers care a lot about streaming, and likely don't care what the attribute is called, other than typing 4 more characters. There will be some migration pain, for sure, but it's probably worth it for an interoperable standard and no compat risk.

So is the concrete proposal that Blink support attributes in perpetuity? With different behaviour? Or the same behaviour? And/or that we do a deprecation/removal for the old attribute name?

In general, when the API OWNERs give the go-ahead for something to ship out ahead of other vendors, particularly when we have worked diligently (as you have) to engage folks with no response, we're staking your claim to the shipped system. Not only did you reach out, but you ran public OTs, discussed at TPAC (among other venues), and did everything I can think of to ground this design in data and developer needs.

It's traumatic for the ecosystem for us to flip-flop (see my mistake w/ WC v0 vs v1 incompatibility), and so we shouldn't do this if there's not an overwhelming reason to do so. Generally, the best stance in this situation is "ok, we tried, you didn't show up, compatible additions only from here on out". Renaming in response to multi-year delays in engagement, after years of developer enthusiasm for a feature, only rewards hostage taking behaviour from trailing projects

Best,

Alex

Mason Freed

unread,
Dec 13, 2022, 12:54:21 PM12/13/22
to Alex Russell, blink-dev, Yoav Weiss, Alex Russell, Chris Wilson
On Fri, Dec 9, 2022 at 10:48 AM Alex Russell <sligh...@chromium.org> wrote:
So is the concrete proposal that Blink support attributes in perpetuity? With different behaviour? Or the same behaviour? And/or that we do a deprecation/removal for the old attribute name?

My plan is to deprecate the old attribute name fairly soon after shipping the new, hopefully-interoperable one. And given the "streaming" carrot that comes with the new attribute, my hope would be that the already low usage of the old attribute drops off fairly quickly and that functionality can be removed.

In general, when the API OWNERs give the go-ahead for something to ship out ahead of other vendors, particularly when we have worked diligently (as you have) to engage folks with no response, we're staking your claim to the shipped system. Not only did you reach out, but you ran public OTs, discussed at TPAC (among other venues), and did everything I can think of to ground this design in data and developer needs.

It's traumatic for the ecosystem for us to flip-flop (see my mistake w/ WC v0 vs v1 incompatibility), and so we shouldn't do this if there's not an overwhelming reason to do so. Generally, the best stance in this situation is "ok, we tried, you didn't show up, compatible additions only from here on out". Renaming in response to multi-year delays in engagement, after years of developer enthusiasm for a feature, only rewards hostage taking behaviour from trailing projects

I don't disagree with your point of view, and I've felt some of this pain. But I'm trying to be pragmatic in getting to an interoperable feature. One place where I'm trying to hold more ground is around the push to eliminate synchronous parsing of DSD.

Thanks,
Mason

Alex Russell

unread,
Dec 13, 2022, 6:31:54 PM12/13/22
to blink-dev, Mason Freed, blink-dev, Yoav Weiss, Alex Russell, Chris Wilson, Alex Russell
Again, I don't understand why we'd remove the old behavior if the new behaviour can live under the same name.

Standards forum debates are not a substitute for developer feedback, and not a reason to break things.

I'm not sure I can be anything but a -1 to an Intent that proposes this without a lot more evidence of developer support for such a name change. Happy to discuss out of band as well.

Best,

Alex

Yoav Weiss

unread,
Dec 14, 2022, 3:41:17 AM12/14/22
to Alex Russell, blink-dev, Mason Freed, Alex Russell, Chris Wilson
I think it can be interesting to consider this rename regardless of other vendors.

Mason - what would happen if we changed the behavior of the current attribute in place without renaming it? What would be the implications for current users of the API?

Mason Freed

unread,
Dec 15, 2022, 1:02:47 PM12/15/22
to Yoav Weiss, Alex Russell, blink-dev, Alex Russell, Chris Wilson
On Wed, Dec 14, 2022 at 12:41 AM Yoav Weiss <yoav...@chromium.org> wrote:
I think it can be interesting to consider this rename regardless of other vendors.

Mason - what would happen if we changed the behavior of the current attribute in place without renaming it? What would be the implications for current users of the API?

The change from non-streaming to streaming, while observable, likely doesn't break too many things. The change did cause a few WPTs to fail, but those were specifically constructed to try to observe the existence of the `<template>` element while the DSD shadow content is being parsed. There are a number of WPTs that test unrelated features but happen to use DSD, and none of those failed when this behavior change was introduced. So I'd say: low risk. The nice part about the attribute rename is that it drops "low risk" to "no risk".

Thanks,
Mason

Alex Russell

unread,
Dec 19, 2022, 3:19:51 PM12/19/22
to Mason Freed, Yoav Weiss, blink-dev, Alex Russell, Chris Wilson
I'm not sure that the rename is "no risk", it only moves the risk onto the ecosystem rather than ourselves.

If we're confident enough, e.g., that there's low use and low chance of breakage for a deprecation, doesn't that also imply that a non-breaking behaviour change should be similarly worth doing under the old name? Or at least trying?

Best,

Alex
Reply all
Reply to author
Forward
0 new messages