On Thu, Dec 8, 2022 at 11:28 PM Alex Russell <[email protected]> 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 <https://github.com/whatwg/html/pull/5465#discussion_r1038099745> (also here <https://github.com/whatwg/html/pull/5465#discussion_r1044667714>) 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 <https://github.com/whatwg/html/pull/5465#discussion_r1038099745>. Thanks for the comments! Mason > Thanks, > > Alex > > On Wednesday, December 7, 2022 at 5:46:20 PM UTC-8 Mason Freed wrote: > >> On Wed, Dec 7, 2022 at 5:33 PM Alex Russell <[email protected]> >> 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 >> >> >> >> >>> Best, >>> >>> Alex >>> >>> On Tuesday, December 6, 2022 at 10:24:20 PM UTC-8 [email protected] >>> wrote: >>> >>>> Great news!! :) >>>> >>>> On Tue, Dec 6, 2022 at 7:05 PM Mason Freed <[email protected]> wrote: >>>> >>>>> Contact [email protected] >>>>> >>>>> Explainerhttps://github.com/whatwg/html/pull/5465 >>>>> https://github.com/whatwg/dom/pull/892 >>>>> >>>>> Specificationhttps://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 componentBlink>DOM>ShadowDOM >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDOM%3EShadowDOM> >>>>> >>>>> 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 tagsdeclarative >>>>> <https://chromestatus.com/features#tags:declarative>, shadow >>>>> <https://chromestatus.com/features#tags:shadow> >>>>> >>>>> TAG review >>>>> >>>>> TAG review statusNot 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 >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ?Yes >>>>> >>>>> Flag nameStreamingDeclarativeShadowDOM >>>>> >>>>> Requires code in //chrome?False >>>>> >>>>> Tracking bughttps://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 >>>>> <https://chromestatus.com/>. >>>>> >>>>> -- >>>>> 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 [email protected]. >>>>> 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 >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDg1Aa7f5j3Kbqag_QwWYpLhAqwkDo0Sv1Xt5mtPCpmkBw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDjzTs-3XtiY9p1Qaruk1oe%3D_GHThnhDdr2Ln3pO7ymQKA%40mail.gmail.com.
