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.