Intent to Ship: Custom property enumeration in getComputedStyle()

[Chromestatus]

Contact emails

se...@chromium.org

Explainer

None

Specification

https://drafts.csswg.org/cssom/#dom-window-getcomputedstyle

Summary

When iterating over window.getComputedStyle(element) in Chromium, there is a bug where it forgets to include any custom properties set on the element. (length() on the returned object forgets to account for the number of custom properties set.) We would like to fix this bug; it brings us closer to web standards, and to Firefox and Safari, which have never had this bug. There is a performance interaction with JavaScript libraries html2canvas and html-to-image; see the document below. More information: https://docs.google.com/document/d/17zz_asZ7E5ITjejp6Q6p4vqzETE3nEa28k2AC01X--s/edit?tab=t.0

Blink component

Blink>CSS

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None

Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

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

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

Yes

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

No

Flag name on about://flags

None

Finch feature name

CSSEnumeratedCustomProperties

Rollout plan

(RARE) Experiment users ramp up over time

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop

141

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).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5070655645155328?gate=5190614048178176

This intent message was generated by Chrome Platform Status.

[Yoav Weiss (@Shopify)]

On Thu, Sep 4, 2025 at 11:20 AM Chromestatus <ad...@cr-status.appspotmail.com> wrote:

Contact emails

se...@chromium.org

Explainer

None

Specification

https://drafts.csswg.org/cssom/#dom-window-getcomputedstyle

Summary

When iterating over window.getComputedStyle(element) in Chromium, there is a bug where it forgets to include any custom properties set on the element. (length() on the returned object forgets to account for the number of custom properties set.) We would like to fix this bug; it brings us closer to web standards, and to Firefox and Safari, which have never had this bug. There is a performance interaction with JavaScript libraries html2canvas and html-to-image; see the document below. More information: https://docs.google.com/document/d/17zz_asZ7E5ITjejp6Q6p4vqzETE3nEa28k2AC01X--s/edit?tab=t.0

Thanks for the description of the issue!

Is there any way to estimate how many sites will be impacted by the slowness here? Do we have a use counter of some sorts? For ones that are impacted, how much slower do they become? Are they still usable?

Would we have some way of pointing the developers of such sites to snapDOM or other solutions?

 

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68b959bd.050a0220.3291f8.0804.GAE%40google.com.

[Steinar H. Gunderson]

On Thu, Sep 04, 2025 at 02:34:08PM +0200, Yoav Weiss (@Shopify) wrote:
> Thanks for the description of the issue!
> Is there any way to estimate how many sites will be impacted by the
> slowness here? Do we have a use counter of some sorts? For ones that are
> impacted, how much slower do they become? Are they still usable?

Yes and no. We want to roll this out via Finch, which will at least give us
confidence that it won't have large-scale problems across the web. As for
individual sites, it really depends on a lot of factors; in particular,
how big are the DOMs, how many custom properties does each element have,
how patient is the user? For most cases, the difference is basically zero.
If you have 2000+ custom properties on each element (something that we don't
recommend, but some extreme sites do it nevertheless), you are talking going
from 15 seconds to several minutes. It is still usable, but the user will
probably eventually tire of waiting if the long is long enough.

It is challenging to make an accurate use counter for this. We could have a
counter like “you are accessing custom properties on gCS and you have more
than 500 of them”, but it would have large amounts of false positives.
For instance, this isn't a problem if you also have a small DOM. It's not a
problem if you see them and immediately skip over them instead of cloning
them onto the new element (the recommended patches to html2canvas and
html-to-image do this). Similarly, I suppose “you are using setProperty to
set more than 500 properties on an element” is going to be very imprecise.

This is why we've been using HTTP Archive to try to quantify the impact
manually, however imprecise. And that tells us that while it's common to
include these libraries, actually hitting them in normal use is not that
common, at least in our normal as-a-user experience.

> Would we have some way of pointing the developers of such sites to snapDOM
> or other solutions?

None beyond the bug reports; we've engaged both on the Chromium bug report we
received as well as bug reports in the relevant upstream libraries (including
pdf.js, which is popular and uses html2canvas), and our experience is that
developers have few problems adjusting as long as they know what the fix is.

Of course, they've already had to contend with this slowness for Firefox and
Safari users; some of them may not care, though. But fixing it for M141
will also fix it for users of those browsers.

/* Steinar */
--
Homepage: https://www.sesse.net/

[Yoav Weiss (@Shopify)]

On Thursday, September 4, 2025 at 2:47:24 PM UTC+2 Steinar H Gunderson wrote:

On Thu, Sep 04, 2025 at 02:34:08PM +0200, Yoav Weiss (@Shopify) wrote:
> Thanks for the description of the issue!
> Is there any way to estimate how many sites will be impacted by the
> slowness here? Do we have a use counter of some sorts? For ones that are
> impacted, how much slower do they become? Are they still usable?

Yes and no. We want to roll this out via Finch, which will at least give us
confidence that it won't have large-scale problems across the web. As for
individual sites, it really depends on a lot of factors; in particular,
how big are the DOMs, how many custom properties does each element have,
how patient is the user? For most cases, the difference is basically zero.
If you have 2000+ custom properties on each element (something that we don't
recommend, but some extreme sites do it nevertheless), you are talking going
from 15 seconds to several minutes.

That sounds equivalent to "completely broken".

 

It is still usable, but the user will
probably eventually tire of waiting if the long is long enough.

It is challenging to make an accurate use counter for this. We could have a
counter like “you are accessing custom properties on gCS and you have more
than 500 of them”, but it would have large amounts of false positives.
For instance, this isn't a problem if you also have a small DOM. It's not a
problem if you see them and immediately skip over them instead of cloning
them onto the new element (the recommended patches to html2canvas and
html-to-image do this). Similarly, I suppose “you are using setProperty to
set more than 500 properties on an element” is going to be very imprecise.

This is why we've been using HTTP Archive to try to quantify the impact
manually, however imprecise. And that tells us that while it's common to
include these libraries, actually hitting them in normal use is not that
common, at least in our normal as-a-user experience.

I can definitely sympathize with the challenge.  But as is, you're essentially telling the API owners that an unknown amount of websites will stop working without warning, and without recourse other than their developers (if any) actively coding their site to use a different library. IMO, that's a hard sell without more data that would help us better quantify the damage.

[Yoav Weiss (@Shopify)]

Looking for that data in your doc, I found a couple of non-public Sheets. Would you be able to summarize your findings from that investigation? It may help us quantify the impact.

 

And that tells us that while it's common to
include these libraries, actually hitting them in normal use is not that
common, at least in our normal as-a-user experience.

I can definitely sympathize with the challenge.  But as is, you're essentially telling the API owners that an unknown amount of websites will stop working without warning, and without recourse other than their developers (if any) actively coding their site to use a different library. IMO, that's a hard sell without more data that would help us better quantify the damage.

> Would we have some way of pointing the developers of such sites to snapDOM
> or other solutions?

None beyond the bug reports; we've engaged both on the Chromium bug report we
received as well as bug reports in the relevant upstream libraries (including
pdf.js, which is popular and uses html2canvas), and our experience is that
developers have few problems adjusting as long as they know what the fix is.

Of course, they've already had to contend with this slowness for Firefox and
Safari users;

Have you reached out to Gecko/WebKit compat teams?
They may have insights on the magnitude here.

[Philip Jägenstedt]

I have made public copies of the sheets and proposed updates in the doc. Also linked below.

Steinar and I analyzed about half of the sites each, so I can say something about the findings.

html2image:

• https://docs.google.com/spreadsheets/d/1w2RuTpw3KG5zFvk9dmRlK-cS38MydyErnsUJzJ12AW8/edit?usp=sharing
• Found by looking for the string "html2image", which appears in an attribute name ("data-html2canvas-ignore") used by the library
• This is a 1% random sample of the results (the total was around 250k)

html-to-image:

• https://docs.google.com/spreadsheets/d/1uV-8cWpLOMfIpo0JnpBpaDmWKznzFe4nqpkOmUyhWGc/edit?usp=sharing (100% of the results)
• Found by looking for the combination of strings "Error inlining remote css file" AND "includeQueryParams" (found by iterating on broader queries with many false positives) 
• These are all of the results

For both libraries, the most common finding by far was that the libraries are loaded, usually as part of a minified bundle, but that we couldn't find any piece of UI on the site that would invoke it. For some sites you could see a plausible usage, but it was behind a login or some kind of checkout flow that we didn't proceed through. For example, a food delivery service might generate a PDF receipt at the end.

We spent at least 5 minutes per site testing, sometimes more. Despite our best efforts in devtools we couldn't find a way to trigger it on any of the sites (30 in total) randomly picked.

I also went to look at a few Swedish sites where I could understand the meaning of everything, and still failed.

Conclusion: Of the sites that embed these libraries, a vast majority either don't actually use them or it's a few steps into some process or behind a login where we cannot reach it. It might still be important, but not to drive-by visitors at least.

Given this, we think that the best approach is to carefully roll this out with Finch and monitor guardrail metrics to ensure no measurable regression. We've provided workarounds for the main libraries we've found (here and here) and think the fact that Firefox and Safari already ship this behavior is reason to think the problem is small.