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 On Thu, Dec 15, 2022 at 10:02 AM Mason Freed <[email protected]> wrote: > > On Wed, Dec 14, 2022 at 12:41 AM Yoav Weiss <[email protected]> > 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 > <https://chromium-review.googlesource.com/c/chromium/src/+/3967571> 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 > > > >> On Wed, Dec 14, 2022 at 12:31 AM Alex Russell <[email protected]> >> wrote: >> >>> 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/CAA44PQi2SXUi4c_ZEGoE5eHpZVZSHwL-1un9CcfTrjSd2K1U8A%40mail.gmail.com.
