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 On Tuesday, December 13, 2022 at 9:54:21 AM UTC-8 Mason Freed wrote: > On Fri, Dec 9, 2022 at 10:48 AM Alex Russell <[email protected]> > 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 > <https://github.com/whatwg/html/pull/5465#discussion_r1047523849>. > > Thanks, > Mason > > > >> 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/2471f016-4265-449f-886c-5e38f9e23245n%40chromium.org.
