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 <[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. >
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 > 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/106ec59f-7f28-45ed-868f-fdd51cec6eeen%40chromium.org.
