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()`, and it shipped in M125. See https://chromestatus.com/feature/5102952270528512 for that feature.
The use counter for getInnerHTML() (https://chromestatus.com/metrics/feature/timeline/popularity/3874) peaked at 0.05% of page loads using this function as of January 2024, and dropped precipitously toward 0.01% in May, 2024. This is presumably due to the shipment of its replacement, getHTML(). While 0.01% still represents high usage for deprecation, the numbers were significantly worse 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. I'd like to remove this feature in M127 in code, with a killswitch (a re-enable switch really) in case of problems.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
None
Shipping on desktop | 127 |
Shipping on Android | 127 |
Shipping on WebView | 127 |
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).
None{Note: I previously sent what should have been an intent to deprecate and remove for this feature. However, that one failed to make it to the right dashboards due to the subject line being incorrect. See that prior conversation right here - it has some good discussion particularly about the use counters, which have improved a lot since January.}
Contact emails
mas...@chromium.orgExplainer
NoneSpecification
NoneSummary
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()`, and it shipped in M125. See https://chromestatus.com/feature/5102952270528512 for that feature.
{Note: This should be the last (!) intent related to the "old" declarative shadow DOM features.}Blink component
Blink>DOM>ShadowDOMTAG review
NoneTAG review status
Not applicableRisks
Interoperability and Compatibility
The use counter for getInnerHTML() (https://chromestatus.com/metrics/feature/timeline/popularity/3874) peaked at 0.05% of page loads using this function as of January 2024, and dropped precipitously toward 0.01% in May, 2024. This is presumably due to the shipment of its replacement, getHTML().
--
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%3DNeDjZJvRAcpSj2cAWi6uW7yYmDV8HdMkqQjFOS3q%3DidB9fQ%40mail.gmail.com.
Interoperability and Compatibility
The use counter for getInnerHTML() (https://chromestatus.com/metrics/feature/timeline/popularity/3874) peaked at 0.05% of page loads using this function as of January 2024, and dropped precipitously toward 0.01% in May, 2024. This is presumably due to the shipment of its replacement, getHTML().
It's great to see the numbers reduce significantly. If the numbers are being migrated to getHTML() though I would have expected https://chromestatus.com/metrics/feature/timeline/popularity/4781 to grow by ~0.04 percentage points, but that one is still significantly lower (although growing). Is it possible that June 1 numbers would show a better balance? Do you by any chance know when the next data point is expected to be visible on chromestatus?I'm also assume people are using a readily available replacement as opposed to just not using getInnerHTML, but it would be nice if number supported that
On Mon, May 27, 2024 at 8:15 AM Vladimir Levin <vmp...@chromium.org> wrote:Interoperability and Compatibility
The use counter for getInnerHTML() (https://chromestatus.com/metrics/feature/timeline/popularity/3874) peaked at 0.05% of page loads using this function as of January 2024, and dropped precipitously toward 0.01% in May, 2024. This is presumably due to the shipment of its replacement, getHTML().
It's great to see the numbers reduce significantly. If the numbers are being migrated to getHTML() though I would have expected https://chromestatus.com/metrics/feature/timeline/popularity/4781 to grow by ~0.04 percentage points, but that one is still significantly lower (although growing). Is it possible that June 1 numbers would show a better balance? Do you by any chance know when the next data point is expected to be visible on chromestatus?I'm also assume people are using a readily available replacement as opposed to just not using getInnerHTML, but it would be nice if number supported thatGreat questions. So AFAIK the use counter plot for the current month is a continuous aggregation. I.e. the 0.0168% I see today (May 28) is as of the 28th, and will change tomorrow (slightly). Given that we're almost to the end of the month, I wouldn't expect a ton of shift. So I think you might be right that this isn't actually a shift to getHTML, but just a shift away from getInnerHTML. See more below.Your questions prompted me to take a closer look at the sample sites still hitting the use counter. I took a close look at the first 10 entries listed, and I think I found perhaps where the big drop came from. Of those ten sites, seven do not use getInnerHTML or getHTML at all. Likely not coincidentally, all seven are Shopify sites. My guess would be that Shopify very recently removed its usage of getInnerHTML?The real issue is that the remaining three sites *do* still use getInnerHTML, and all three throw exceptions when the feature is disabled. I can't perceive anything broken on the site, but the exception isn't a good sign. A few interesting tidbits: one of the three does appear to (properly) feature-detect getInnerHTML() yet an exception is still thrown that might or might not be related. The other two do not feature detect, and the exception is clear: "getInnerHTML is not a function". Very interestingly, none of the three use getInnerHMTL for anything declarative shadow dom related. They seem to just be using it as a way to get the innerHTML value. All three seem to be hand-written JS, so it's possible the sites were developed on Chrome in the last few years and the developer didn't notice that they should have done foo=el.innerHTML instead of foo=el.getInnerHTML().Given that the use counter is very low (0.01%), I'd still like to push ahead with this deprecation. The above sites likely represent interop problems, since they'll break on other browsers already today. But I'd like to revise my plan: instead of going immediately to 100% removal, I'd like to use a slow ramp down over time, to monitor for reported breakage.Thoughts?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDh_myM1eudBh_%3DeY4F9UZN9vZxRa9%2BmV9vKSR9Nh1iHhw%40mail.gmail.com.
On Tue, May 28, 2024 at 12:30 PM Mason Freed <mas...@chromium.org> wrote:On Mon, May 27, 2024 at 8:15 AM Vladimir Levin <vmp...@chromium.org> wrote:Interoperability and Compatibility
The use counter for getInnerHTML() (https://chromestatus.com/metrics/feature/timeline/popularity/3874) peaked at 0.05% of page loads using this function as of January 2024, and dropped precipitously toward 0.01% in May, 2024. This is presumably due to the shipment of its replacement, getHTML().
It's great to see the numbers reduce significantly. If the numbers are being migrated to getHTML() though I would have expected https://chromestatus.com/metrics/feature/timeline/popularity/4781 to grow by ~0.04 percentage points, but that one is still significantly lower (although growing). Is it possible that June 1 numbers would show a better balance? Do you by any chance know when the next data point is expected to be visible on chromestatus?I'm also assume people are using a readily available replacement as opposed to just not using getInnerHTML, but it would be nice if number supported thatGreat questions. So AFAIK the use counter plot for the current month is a continuous aggregation. I.e. the 0.0168% I see today (May 28) is as of the 28th, and will change tomorrow (slightly). Given that we're almost to the end of the month, I wouldn't expect a ton of shift. So I think you might be right that this isn't actually a shift to getHTML, but just a shift away from getInnerHTML. See more below.Your questions prompted me to take a closer look at the sample sites still hitting the use counter. I took a close look at the first 10 entries listed, and I think I found perhaps where the big drop came from. Of those ten sites, seven do not use getInnerHTML or getHTML at all. Likely not coincidentally, all seven are Shopify sites. My guess would be that Shopify very recently removed its usage of getInnerHTML?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2MvNLyYnrF2q%2BhEx8EAoiZsC_ws3Bj3%3DOw7K5m-hRAvDQ%40mail.gmail.com.
Deprecating seems fine, especially since it's a relatively new API and less likely to be used on non-maintained sites, but removal seems a bit premature even if done slowly. Would it be better to let it bake a few milestones and see if a scary deprecation message threatening removal after the summer drives the usage down?
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJ_LsKuzR2FezpC4cxyFsb5nUaG65LeidpyfSmFWVGJaQ%40mail.gmail.com.
Deprecating seems fine, especially since it's a relatively new API and less likely to be used on non-maintained sites, but removal seems a bit premature even if done slowly. Would it be better to let it bake a few milestones and see if a scary deprecation message threatening removal after the summer drives the usage down?
Your questions prompted me to take a closer look at the sample sites still hitting the use counter. I took a close look at the first 10 entries listed, and I think I found perhaps where the big drop came from. Of those ten sites, seven do not use getInnerHTML or getHTML at all. Likely not coincidentally, all seven are Shopify sites. My guess would be that Shopify very recently removed its usage of getInnerHTML?FWIW, internal code search brought up nothing. It's possible that this is a 3P app that changed their use. (or that I'm simply failing to find the relevant change :D)
The plan to ramp down usage is a good one, although as we previously discussed in a different thread, it may cause some debugging challenges for developers. It is worthwhile to also reach out to some of the developers whose sites you noticed would throw an exception -- just an FYI email that this feature is being removed. Given the fairly low usage, readily available fixes (via getHTML() or possibly innerHTML) and your commitment to monitor for breakages, this looks good to me.
LGTM3 for the deprecation in 127. I'd like to hold off on stamping the removal approval until later but threatening (well, targetting) removal in 129 seems ok.
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDhoYiq3D6HFupxGhQL1SOSKVUFD%3DxQJGXTamyDvPTDr2A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BZW0sf1J4s1qCVQaLKZnQZ7712WXn%3D5v4rZPGb0AgtFQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_2jbdZe6%3DMphTATNLym9C1E2M80hUfa%2BgzucajxKxXDA%40mail.gmail.com.