Intent to Deprecate: non-standard `shadowroot` attribute for declarative shadow DOM

[Mason Freed]

Contact emails

mas...@chromium.org

Explainer

None

Specification

https://github.com/whatwg/html/pull/5465

Summary

The standards-track `shadowrootmode` attribute, which enables declarative Shadow DOM, was shipped in Chrome 111. The older, non-standard `shadowroot` attribute is now deprecated. During the deprecation period, both attributes are functional, however the `shadowroot` attribute does not enable the new streaming behavior, whereas `shadowrootmode` allows streaming of content. There is a straightforward migration path: replace `shadowroot` with `shadowrootmode`.

Blink component

Blink>DOM>ShadowDOM

Search tags

declarative, shadow, dom, shadowroot

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The current (2-10-23) usage of `shadowroot` is 0.01% [1], which is relatively high. The hope is that as developers learn about the now-standardized `shadowrootmode` attribute, and understand that it: 1. supports streaming (which is preferred), and 2. is standardized, and should appear soon in other browsers ...they will naturally migrate away from the `shadowroot` attribute, and usage will drop. We will continue to monitor the usage and will only attempt to remove the old attribute's functionality when usage is sufficiently small. With this deprecation, a warning will appear in the DevTools issues pane, which should help with developer education. [1] https://chromestatus.com/metrics/feature/timeline/popularity/3196

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

Activation

Developer outreach will be important, to educate developers about the new `shadowrootmode` attribute and behavior.

Security

Not really applicable to this deprecation, but the security/XSS issues that applied to `shadowroot` also apply to `shadowrootmode`. See https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#security-and-privacy-considerations. I do not think this deprecation affects that issue.

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

N/A

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

Flag name

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1396384

Estimated milestones

DevTrial on desktop

112

DevTrial on Android

112

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6239658726391808

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

Do you have any predicted end milestone for the deprecation? What does current usage look like?

+Jason Robbins - FYI, this didn't make it to the chromestatus tool.

--
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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDhn62d2CEDggcQW0qW4EUiTX9GmMkesQp-1dPd4uRXndA%40mail.gmail.com.

[Mason Freed]

On Wed, Feb 15, 2023 at 10:14 PM Yoav Weiss <yoav...@chromium.org> wrote:

Do you have any predicted end milestone for the deprecation? What does current usage look like?

So usage has ticked up recently, to about 0.01%. I think the spike is due to recent interest from other implementers, and the coming standardization of this feature. However, I expect that usage to migrate to the new attribute fairly quickly, since it is likely made up of early adopters that are keeping up to date with this feature. Having said that, I don't know how long it'll take. I would not be surprised if it takes until the end of the year for usage to be low enough that it isn't concerning. That would put it around M122 or so. I know this isn't concrete, but let me know if it answers your question!

Thanks,

Mason

[Jason Robbins]

On Wednesday, February 15, 2023 at 10:14:48 PM UTC-8 yoav...@chromium.org wrote:

+Jason Robbins - FYI, this didn't make it to the chromestatus tool.

I have an idea about what went wrong.

"Intent to deprecate" is the subject line that is expected for the first stage in the deprecation process.  It was detected as such, but that stage does not require any review.    Based on this thread and the contents of the feature entry it looks like the final stage was what needed to be reviewed.

The final stage detects an intent email with the subject line "Intent to ship" or "Intent to remove".  The launching-features page uses "Intent to ship" for the final stage of a deprecation, and when we generate the email preview we use that subject line, but I'm guessing that it sounded wrong so Mason edited it.  

It would probably be better if chromestatus generated a preview with the subject line "Intent to remove" and we updated launching-features to use that wording too.  I am tracking the issue here:

https://github.com/GoogleChrome/chromium-dashboard/issues/2749

Thanks,

jason!

 

[Mason Freed]

On Thu, Feb 16, 2023 at 5:19 PM Jason Robbins <jrob...@google.com> wrote:

On Wednesday, February 15, 2023 at 10:14:48 PM UTC-8 yoav...@chromium.org wrote:

+Jason Robbins - FYI, this didn't make it to the chromestatus tool.

I have an idea about what went wrong.

"Intent to deprecate" is the subject line that is expected for the first stage in the deprecation process.  It was detected as such, but that stage does not require any review.    Based on this thread and the contents of the feature entry it looks like the final stage was what needed to be reviewed.

Sorry - this was my fault. The stages of deprecation are kind of different, and the two options I had for this "deprecation" (not "removal") were "Draft Ready for Trial email" and "Draft Intent to Ship email". I chose the latter and renamed the subject line to "Intent to Deprecate". I hadn't realized we had tooling look at these emails. I guess the right thing was to choose the "Ready for Trial" email template, and not change the subject line. Perhaps a suggestion would be to rename those links or add help text explaining which one is appropriate at each stage for a deprecation/removal intent?

Thanks,

Mason

[Yoav Weiss]

That uptick may suggest a single large entity that started using this, and may be easy to move to the new attribute.

Have you tried turning the usecounter into a UKM to try and see where the usage is coming from?

The other alternative is that some developer documentation is pointing at the old attribute name. Can you verify that's not the case?

Otherwise, we typically prefer to have deprecation messages with clear milestones for their removal date. It seems to me that a year may be a lot for this. Would you be comfortable with setting the removal date for 6 milestones ahead? Maybe the UKM analysis can change our thinking here?

[Mason Freed]

On Sun, Feb 19, 2023 at 11:33 PM Yoav Weiss <yoav...@chromium.org> wrote:

That uptick may suggest a single large entity that started using this, and may be easy to move to the new attribute.

Have you tried turning the usecounter into a UKM to try and see where the usage is coming from?

Agreed, that uptick is likely a single party. My hope is that it will go back down as that entity moves to the new attribute. Adding a UKM sounds like a reasonable idea - I'll do that if I don't see a down-trend in the usecounter data soon.

 

The other alternative is that some developer documentation is pointing at the old attribute name. Can you verify that's not the case?

Indeed that's very likely. Our own blog post still describes the old attribute. (I'm working on getting that updated.)

 

Otherwise, we typically prefer to have deprecation messages with clear milestones for their removal date. It seems to me that a year may be a lot for this. Would you be comfortable with setting the removal date for 6 milestones ahead? Maybe the UKM analysis can change our thinking here?

I'm reasonably comfortable with targeting 6 milestones out. That'd be roughly M118 as the last version that supports the old `shadowroot` attribute, and M119 as the first that doesn't. And closer to the deadline we can re-evaluate usage and make sure it's low enough for comfort. Does that sound reasonable? If so, I'll update the documentation and console messages accordingly.

Thanks,

Mason

[Manuel Rego Casasnovas]

Hi Mason,

Are we planning to use deprecation reports (reporting API) for this
deprecation?

As a side note, I've realized we don't mention that at
https://www.chromium.org/blink/launching-features/#feature-deprecations
We only mention:
"At this point, you should also notify developers by adding a
deprecation console message, pointing to the updated status entry in the
console message."
Should we update that?

Cheers,
Rego

On 21/02/2023 22:36, Mason Freed wrote:
>
>
> On Sun, Feb 19, 2023 at 11:33 PM Yoav Weiss <yoav...@chromium.org
> <mailto:yoav...@chromium.org>> wrote:
>
> That uptick may suggest a single large entity that started using
> this, and may be easy to move to the new attribute.
> Have you tried turning the usecounter into a UKM

> <https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/ukm_features.cc;l=32?q=usecounter%20ukm&ss=chromium> to try and see where the usage is coming from?

>
>
> Agreed, that uptick is likely a single party. My hope is that it will go
> back down as that entity moves to the new attribute. Adding a UKM sounds
> like a reasonable idea - I'll do that if I don't see a down-trend in the
> usecounter data soon.
>  
>
> The other alternative is that some developer documentation is
> pointing at the old attribute name. Can you verify that's not the case?
>
>
> Indeed that's very likely. Our own blog post

> <https://web.dev/declarative-shadow-dom/> still describes the old

> attribute. (I'm working on getting that updated.)
>  
>
> Otherwise, we typically prefer to have deprecation messages with
> clear milestones for their removal date. It seems to me that a year
> may be a lot for this. Would you be comfortable with setting the
> removal date for 6 milestones ahead? Maybe the UKM analysis can
> change our thinking here?
>
>
> I'm reasonably comfortable with targeting 6 milestones out. That'd be
> roughly M118 as the last version that supports the old `shadowroot`
> attribute, and M119 as the first that doesn't. And closer to the
> deadline we can re-evaluate usage and make sure it's low enough for
> comfort. Does that sound reasonable? If so, I'll update the
> documentation and console messages accordingly.
>
> Thanks,
> Mason
>
>  
>
>
> On Fri, Feb 17, 2023 at 6:38 PM Mason Freed <mas...@chromium.org
> <mailto:mas...@chromium.org>> wrote:
>
>
> On Thu, Feb 16, 2023 at 5:19 PM Jason Robbins
> <jrob...@google.com <mailto:jrob...@google.com>> wrote:
>
> On Wednesday, February 15, 2023 at 10:14:48 PM UTC-8

> https://github.com/GoogleChrome/chromium-dashboard/issues/2749 <https://github.com/GoogleChrome/chromium-dashboard/issues/2749>
>
> Thanks,
> jason!

>
>  
>
> --
> 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 blink-dev+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDjxoGAfpfBkPLdKJjGTV2T0bY4jnynhhNnEQ4bK%2BAnxKg%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDjxoGAfpfBkPLdKJjGTV2T0bY4jnynhhNnEQ4bK%2BAnxKg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Yoav Weiss]

On Wed, Feb 22, 2023 at 8:35 AM Manuel Rego Casasnovas <re...@igalia.com> wrote:

Hi Mason,

Are we planning to use deprecation reports (reporting API) for this
deprecation?

As a side note, I've realized we don't mention that at
https://www.chromium.org/blink/launching-features/#feature-deprecations
We only mention:
"At this point, you should also notify developers by adding a
deprecation console message, pointing to the updated status entry in the
console message."
Should we update that?

We definitely should be more specific and point Chromium devs to use UseCounter::CountDeprecation in order to trigger Deprecation Reports.

+Ari Chivukula - are there further hoops one needs to jump through nowadays to ensure the deprecation message is meaningful?

[Mason Freed]

On Tue, Feb 21, 2023 at 11:45 PM Yoav Weiss <yoav...@chromium.org> wrote:

On Wed, Feb 22, 2023 at 8:35 AM Manuel Rego Casasnovas <re...@igalia.com> wrote:

Are we planning to use deprecation reports (reporting API) for this
deprecation?

As a side note, I've realized we don't mention that at
https://www.chromium.org/blink/launching-features/#feature-deprecations
We only mention:
"At this point, you should also notify developers by adding a
deprecation console message, pointing to the updated status entry in the
console message."
Should we update that?

We definitely should be more specific and point Chromium devs to use UseCounter::CountDeprecation in order to trigger Deprecation Reports.

+Ari Chivukula - are there further hoops one needs to jump through nowadays to ensure the deprecation message is meaningful?

So I'm using Deprecation::CountDeprecation(), which I believe (hope?) hooks into the reporting API. That process is fairly well documented here, so I hope it's the right path to be on.

Thanks,

Mason

 

[Ari Chivukula]

That is the correct path! Updating the docs here: https://chromium-review.googlesource.com/c/website/+/4289233

~ Ari Chivukula (Their/There/They're)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDgNj_wUt72ppnFvmcdgNpfK1HDOXg39_Xd6zh-dArb%2Bzw%40mail.gmail.com.

[Mason Freed]

I'm checking back in on this deprecation thread. In the intervening 5 milestones, the use counter for the deprecated attribute has unfortunately increased, rather than decreased. The old attribute is seen on 0.025% of page loads, just slightly more than the new shadowrootmode attribute which is at 0.02%. I'm adding a UKM to look into which sites are the culprits, but I'd also like to start Finch-disabling the feature for a portion of Canary/Dev and maybe Beta users, to suss out problems and improve visibility of this deprecation to site owners. We're now about 3 months out from 119 (the target removal milestone) going to stable. Any objections?

Thanks,

Mason

[Mike Taylor]

That sounds fine to me. Side question: would it be possible to treat shadowroot as a legacy alias of shadowrootmode, in case usage doesn't go down?

--

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 blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5d29f2c2-44ce-4ca0-8f96-e2de71399871n%40chromium.org.

[Mason Freed]

On Tue, Aug 15, 2023 at 2:39 AM Mike Taylor <mike...@chromium.org> wrote:

That sounds fine to me. Side question: would it be possible to treat shadowroot as a legacy alias of shadowrootmode, in case usage doesn't go down?

Yes, I believe that would likely be web compatible. The difference in behavior between the two attributes is subtle and not likely to cause issues, so in the worst case, we could go down this road. I'm still hoping it's possible to remove `shadowroot` though. I'd be surprised if too many sites are using `shadowroot` without feature detection, given that it's Chromium only. But I'll keep that idea in my back pocket, thanks.

Thanks,

Mason

[Alex Russell]

I'd like, once again, to emphasise that this change is not strictly necessary and the bikeshedding is against policy. I'm not sure why we're doing this instead of introducing the new behaviour behind the old name and holding that line.

Best,

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Mason Freed]

Checking back in on this deprecation thread. The use counter for the deprecated shadowroot attribute has plateaued at about 0.045% of page loads. I have had the feature disabled for 50% of Canary, Dev, and Beta since July, and I have received exactly zero bug reports. Based on that, plus my strong belief that any existing usage must be use-counted or it would already be broken in all other browsers, I'd like to attempt to slowly disable the feature, via Finch, starting in 119. My plan would be to move to 1% of stable when 119 is released, holding for several weeks to monitor for breakage. If none is reported, I'll move to 2% for another week, etc. Any objections?

Thanks,

Mason

[Mason Freed]

Hearing no objections, I'm moving forward with this feature removal starting in M119.

Thanks,

Mason

[Mason Freed]

Closing the loop - the old `shadowroot` attribute was successfully removed from Blink over M119/M120. It's now fully disabled everywhere. No bugs were reported.

Thanks,

Mason