Intent to Prototype: *Streaming* declarative shadow DOM

[Mason Freed]

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

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. 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]

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]

+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]

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]

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]

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]

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]

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]

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]

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]

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]

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