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/CAM%3DNeDjLJ-Ls1Y6KT0Z8zv9kW4op3mkdAnZ5b2rXbv88Lzo%2B5g%40mail.gmail.com.
