Intent to Deprecate non-standard declarative shadow DOM serialization

[Mason Freed]

Contact emails

mas...@chromium.org

Explainer

https://github.com/whatwg/html/issues/8867#issuecomment-1856696628

Specification

None

Summary

The prototype implementation (which was shipped in 2020 and then shape-changed in 2023) contained a method called `getInnerHTML()` that could be used to serialize DOM trees containing shadow roots. That part of the prototype was not standardized with the rest of declarative shadow dom, and only recently has it reached spec consensus (https://github.com/whatwg/html/issues/8867). As part of that consensus, the shape of the getInnerHTML API changed. This feature represents the deprecation of the old, shipped `getInnerHTML()` method. The replacement is called `getHTML()`: see https://chromestatus.com/guide/edit/5102952270528512.

Blink component

Blink>DOM>ShadowDOM

Motivation

The standardized method, getHTML(), has the chance at being interoperable, while this version (getInnerHTML) does not.

Initial public proposal

https://github.com/whatwg/html/issues/8867#issuecomment-1856696628

TAG review

None

TAG review status

Pending

Risks

Interoperability and Compatibility

The use counter for getInnerHTML() (https://chromestatus.com/metrics/feature/timeline/popularity/3874) shows 0.04% of page loads using this function as of January 2024. That represents high usage for deprecation, however, the numbers were quite similar for the deprecation of the old `shadowroot` attribute, and the removal of that feature generated zero bug reports. It is my strong belief that since this feature is only shipped in Chrome, the vast majority of usage is guarded by feature checks. So this deprecation should be safer than it would seem from the numbers. My plan is to very slowly disable the API and monitor closely for bug reports. That approach was quite successful for the removal of shadowroot. If bugs are reported, I'll back off and make a new plan.

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

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?

None

Debuggability

None

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

No

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1519972

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5081733588582400

This intent message was generated by me, manually, because of this bug.

[Vladimir Levin]

On Fri, Jan 19, 2024 at 3:13 PM Mason Freed <mas...@chromium.org> wrote:

Contact emails

mas...@chromium.org

Explainer

https://github.com/whatwg/html/issues/8867#issuecomment-1856696628

Specification

None

Summary

The prototype implementation (which was shipped in 2020 and then shape-changed in 2023) contained a method called `getInnerHTML()` that could be used to serialize DOM trees containing shadow roots. That part of the prototype was not standardized with the rest of declarative shadow dom, and only recently has it reached spec consensus (https://github.com/whatwg/html/issues/8867). As part of that consensus, the shape of the getInnerHTML API changed. This feature represents the deprecation of the old, shipped `getInnerHTML()` method. The replacement is called `getHTML()`: see https://chromestatus.com/guide/edit/5102952270528512.

Blink component

Blink>DOM>ShadowDOM

Motivation

The standardized method, getHTML(), has the chance at being interoperable, while this version (getInnerHTML) does not.

Initial public proposal

https://github.com/whatwg/html/issues/8867#issuecomment-1856696628

TAG review

None

TAG review status

Pending

Risks

Interoperability and Compatibility

The use counter for getInnerHTML() (https://chromestatus.com/metrics/feature/timeline/popularity/3874) shows 0.04% of page loads using this function as of January 2024. That represents high usage for deprecation, however, the numbers were quite similar for the deprecation of the old `shadowroot` attribute, and the removal of that feature generated zero bug reports. It is my strong belief that since this feature is only shipped in Chrome, the vast majority of usage is guarded by feature checks. So this deprecation should be safer than it would seem from the numbers. My plan is to very slowly disable the API and monitor closely for bug reports. That approach was quite successful for the removal of shadowroot. If bugs are reported, I'll back off and make a new plan.

I agree that I expect most uses to be feature checked. That being said, have you tried to figure out where the 0.04% is coming from? Is it a lot of small uses or a few big sites that keep using it? If it's the latter, it may be worth it to reach out.

--
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%3DNeDhpHobDUy1VwZ2rmy5DBUVfsm8ijXOEtk%2B1eHjJgu6FRg%40mail.gmail.com.

[Mason Freed]

On Friday, January 19, 2024 at 12:27:50 PM UTC-8 vmp...@google.com wrote:

Interoperability and Compatibility

The use counter for getInnerHTML() (https://chromestatus.com/metrics/feature/timeline/popularity/3874) shows 0.04% of page loads using this function as of January 2024. That represents high usage for deprecation, however, the numbers were quite similar for the deprecation of the old `shadowroot` attribute, and the removal of that feature generated zero bug reports. It is my strong belief that since this feature is only shipped in Chrome, the vast majority of usage is guarded by feature checks. So this deprecation should be safer than it would seem from the numbers. My plan is to very slowly disable the API and monitor closely for bug reports. That approach was quite successful for the removal of shadowroot. If bugs are reported, I'll back off and make a new plan.

I agree that I expect most uses to be feature checked. That being said, have you tried to figure out where the 0.04% is coming from? Is it a lot of small uses or a few big sites that keep using it? If it's the latter, it may be worth it to reach out.

That's a good point. So I just took a look a the top 8 users from the use counter page. Of those, 2 do not contain any usage of getInnerHTML(). All 6 of the remainder come from one single library,  "Auryc JavaScript Client-Side Library". And that library a) already feature checks for declarative shadow DOM before using getInnerHTML(), and further b) feature checks the *old* `shadowroot` attribute. So I suspect the use counter is already overcounting the usage -  see this bug for why.

Thanks for pushing on this - let me know if the above convinces you that the risk should be low.

Thanks,

Mason

  

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

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?

None

Debuggability

None

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

Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Tracking bughttps://crbug.com/1519972

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5081733588582400

This intent message was generated by me, manually, because of this bug.

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

[Vladimir Levin]

On Fri, Jan 19, 2024 at 7:54 PM Mason Freed <mas...@chromium.org> wrote:

On Friday, January 19, 2024 at 12:27:50 PM UTC-8 vmp...@google.com wrote:

Interoperability and Compatibility

The use counter for getInnerHTML() (https://chromestatus.com/metrics/feature/timeline/popularity/3874) shows 0.04% of page loads using this function as of January 2024. That represents high usage for deprecation, however, the numbers were quite similar for the deprecation of the old `shadowroot` attribute, and the removal of that feature generated zero bug reports. It is my strong belief that since this feature is only shipped in Chrome, the vast majority of usage is guarded by feature checks. So this deprecation should be safer than it would seem from the numbers. My plan is to very slowly disable the API and monitor closely for bug reports. That approach was quite successful for the removal of shadowroot. If bugs are reported, I'll back off and make a new plan.

I agree that I expect most uses to be feature checked. That being said, have you tried to figure out where the 0.04% is coming from? Is it a lot of small uses or a few big sites that keep using it? If it's the latter, it may be worth it to reach out.

That's a good point. So I just took a look a the top 8 users from the use counter page. Of those, 2 do not contain any usage of getInnerHTML(). All 6 of the remainder come from one single library,  "Auryc JavaScript Client-Side Library". And that library a) already feature checks for declarative shadow DOM before using getInnerHTML(), and further b) feature checks the *old* `shadowroot` attribute. So I suspect the use counter is already overcounting the usage -  see this bug for why. 

Thanks for pushing on this - let me know if the above convinces you that the risk should be low.

Yeah, I think the risk is low here.

FWIW, I couldn't find any relevant github or contact info for this library but if you had better luck finding contact information, we might as well file an issue or send an email.

[Mason Freed]

On Mon, Jan 22, 2024 at 8:05 AM Vladimir Levin <vmp...@google.com> wrote:

Yeah, I think the risk is low here.

Great, thanks!

 

FWIW, I couldn't find any relevant github or contact info for this library but if you had better luck finding contact information, we might as well file an issue or send an email.

I also tried to find it, but failed. It appears to be closed source.

Thanks,

Mason

[Dan Clark]

I guess a theoretical risk is that someone feature-checks for HTMLTemplateElement.shadowRootMode and then assumes the existence of getInnerHTML() based on that check. But given the lack of usage in the top sites I agree that this seems to not be an issue in practice.

I saw that there's a support email listed at https://www.heap.io/auryc. Maybe worth a ping?

-- Dan

[Daniel Bratell]

Unreliable use counters sound scary. We base a lot of decisions off those. So far they have only been shown to over-count though? But still, would be great if someone could get a grip on that bug and either fix it or make us understand what is going on.

For this feature, what is the status of getHTML()? Can we redirect users to it already?

/Daniel

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/bc371f9a-e39b-40cb-9941-c0b4dcc76342n%40chromium.org.

[Yoav Weiss (@Shopify)]

Also, what are the timelines you have in mind in terms of deprecation?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8357e80a-5b6b-4c73-83e7-de19e8ca1a37%40gmail.com.

[Mason Freed]

On Wed, Jan 24, 2024 at 8:10 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

Also, what are the timelines you have in mind in terms of deprecation?

I'd like to try starting to turn the feature off ASAP, in M123, to avoid an effect I've discovered where usage spikes when I announce deprecations. I would very slowly enable, likely over about 2 months/milestones. Let me know if that sounds ok. That's about the schedule I used for the `shadowroot` attribute, and that was successful.

 

On Wed, Jan 24, 2024 at 4:51 PM Daniel Bratell <brat...@gmail.com> wrote:

Unreliable use counters sound scary. We base a lot of decisions off those. So far they have only been shown to over-count though? But still, would be great if someone could get a grip on that bug and either fix it or make us understand what is going on.

Yeah, I agree. In my experience (which tends to be a lot of deprecations) the usage is always over-counted. My rough theory, if correct, doesn't always mean usage will be over-counted though.

For this feature, what is the status of getHTML()? Can we redirect users to it already?

 It's implemented, and here's the chromestatus for that. I haven't shipped it yet, but my plan is to do that ASAP. Ideally I ship it in M123, to coincide with this deprecation.

On 2024-01-23 20:38, 'Dan Clark' via blink-dev wrote:

I guess a theoretical risk is that someone feature-checks for HTMLTemplateElement.shadowRootMode and then assumes the existence of getInnerHTML() based on that check. But given the lack of usage in the top sites I agree that this seems to not be an issue in practice.

I suppose that's a theoretical risk, yes. I bet (hope?) it's rare though. 

I saw that there's a support email listed at https://www.heap.io/auryc. Maybe worth a ping?

Thanks, I'll give them a ping. I'm not sure it's worth it, given that the existing feature detection is already disabled by the lack of the `shadowroot` attribute. But no harm.

Thanks,

Mason

[Yoav Weiss (@Shopify)]

Is this thread meant for both deprecation and removal (given the short timelines)?

Apologies for the delay in responding here. It might be worthwhile to re-send it with the right title, as it's currently not caught in the API owner's tooling (I suspect that's due to a missing ":").

On Fri, Jan 26, 2024 at 11:30 PM Mason Freed <mas...@chromium.org> wrote:

On Wed, Jan 24, 2024 at 8:10 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

Also, what are the timelines you have in mind in terms of deprecation?

I'd like to try starting to turn the feature off ASAP, in M123, to avoid an effect I've discovered where usage spikes when I announce deprecations.

That's odd..

[Mason Freed]

On Tue, Feb 6, 2024 at 1:26 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

Is this thread meant for both deprecation and removal (given the short timelines)?

Apologies for the delay in responding here. It might be worthwhile to re-send it with the right title, as it's currently not caught in the API owner's tooling (I suspect that's due to a missing ":").

Yes, I did hope to do both with this one intent. I’ve learned not to edit the title of the email (e.g. to say “deprecate AND remove” because then the tool definitely doesn’t pick it up. I’m not sure what happened to the :, I didn’t edit it. Sorry for the trouble, and thanks for catching it.

So I should re-send the entire thing?

[Jason Robbins]

If you intend to deprecate and remove, that is the "Prepare to ship" stage on your chromestatus feature entry.  You can use the review gate chips to access the intent preview and then copy and paste that to start the thread.

https://screenshot.googleplex.com/5GioLEtEnQBvTZu

The subject line will be "Intent to Ship: Deprecation of non-standard declarative shadow DOM serialization".  Using "Intent to deprecate and remove" should also work.  ChromeStatus doesn't actually look for the colon in the subject line, it just looks for keywords near the start of the subject line, and it looks for the body line "Link to entry on the Chrome Platform Status" and the link to your entry.

Thanks,

jason!