I think the 2.37% use case is definitely interesting since if scrapers
are causing this, I would expect the number to either be much higher
(scrapers accessing this on most sites) or much lower (it's a
negligible use case).
That being said, I'm also not convinced that these are "real
developers" doing this on more than 2% of sites.
Is it possible to check httparchive for a random sampling of websites
that trigger this UMA and see if there is a pattern that emerges or
whether there is script that accesses these properties?
In either case, in light of both Firefox and Safari shipping and the
fact that outlines don't affect box geometry, I'm inclined to approve
with a note to be cautious in launching this and follow a finch
rollout that propagates the feature to the stable channel slowly.
With that, LGTM1.
Also, it would be nice to follow up about the 2.37% to see if there is
a solid explanation
Thanks,
Vlad
On Monday, February 2, 2026 at 3:05:48 PM UTC-5 Alex Russell wrote:
Why would scrapers opt into metrics reporting? Seems an unlikely
explanation for elevated use. Do we have other views onto it, e.g.
from Edge histograms?
Best,
Alex
On Thursday, January 29, 2026 at 2:53:02 PM UTC-8 Sam Davis
Omekara wrote:
Hi,
Thanks for the questions. Find below my responses:
* Question: As a non-CSS expert, can you help me better
understand what "applying that special-case becomes
ambiguous and difficult to define consistently"? Is this
in terms of code that authors would write, or prose for
spec authors? An example would be helpful here.
o Answer: The ambiguity is primarily around spec
semantics. Gap decorations extended the column-rule-*
properties to accept value lists and `repeat()`
patterns. The previous rule (“if style is none/hidden,
then computed width is 0”) is straightforward for a
single value, but with lists and repeats you no longer
have a clean, well-defined way of expressing this
behavior. For example, from the CSSWG discussion:
+ column-rule-style: solid dashed none;
+ column-rule-width: 1px 2px;
o This cycles to: “1px solid, 2px dashed, (1px) none,
2px solid, 1px dashed, (2px) none …”.
o Setting the width to zero in this case depending on
the style at any point in the expansion isn’t
well-defined.
o Also, `repeat()` syntax is preserved at computed-value
time, which further prevents expanding lists and
applying a clean index-based rule:
+ column-rule-style: repeat(2, solid none dashed);
+ column-rule-width: 1px 2px;
o This would expand to: “1px (solid), 2px (none),
1px(dashed), 2px(solid), 1px(none), 2px (dashed) …”
But computed values explicitly do not perform this
expansion, so any rule that depends on per-index
alignment between style and width cannot be spec'd in
a well-defined way.
* Question: 2.37% of page views is a lot of page views. Why
do we feel confident that border-width needs backwards
compat considerations for getComputedStyle but
column-rule-width and outline-width don't? Are you saying
that 2.37% of the use counters are coming from
fingerprinting? I'm also not sure what it means for a
scraper to trigger a UseCounter - can you clarify? I've
typically thought of scraping as a server-side operation -
are these web extensions?
o Why do we feel confident that border-width needs
backwards compat considerations for getComputedStyle
and column-rule-width and outline-width don’t?
+ `border-*-width` properties are more commonly used
and are tied to the box model, so changing what
getComputedStyle() returns is more likely to
affect existing scripts that compute geometry or
layout related behavior. In contrast,
outline-width and column-rule-width are less
commonly used and are only used for visual
decoration so returning the author-specified width
rather than 0px should not affect the element’s
geometry, making user-visible regressions less likely.
o On the 2.37%
+ The use counter added was scoped to trigger when
the resolved value gotten from getComputedStyle is
called on an element where style is none/hidden
but width is non-zero. While 2.37% is high we
believe the traffic is dominated by:
# Fingerprinting/Telemetry scripts that
typically iterate over every CSS property to
build a unique “fingerprint” of the browser.
# Generic serializers that read all styles to
copy/paste or inspect elements
+ The default for these properties is *-width:
medium and *-style: none. This is also a
contributing factor to this high percentage. So
even if a site doesn’t explicitly set these values
and is being scraped, by virtue of the defaults,
the counter will get hit.
+ On scrapers being server side
# In recent times, we’ve seen scrapers be
headless browser automation like Puppeteer or
Selenium or client-side scripts in real
browsers. They can execute Javascript and call
getComputedStyle which in this case would
expect the counter to be hit.
These tools often query hundreds of properties
which signals that a high query rate does not
necessarily imply meaningful web-facing
dependence on the current behavior.
+ Also, we are not first movers in this case, Webkit
and Gecko have shipped this.
+ + [email protected] for more details on this.
On Thursday, January 22, 2026 at 6:21:07 PM UTC-8 Mike Taylor
wrote:
On 1/21/26 1:46 p.m., Chromestatus wrote:
*Contact emails*
[email protected], [email protected]
*Explainer*
/No information provided/
*Specification*
https://github.com/w3c/csswg-drafts/pull/11913/files
<https://github.com/w3c/csswg-drafts/pull/11913/files>
*Summary*
This proposal untangles ‘border-width’, ‘outline-width’,
and ‘column-rule-width’ from their corresponding
‘*-style’ properties. Previously, if a ‘*-style’
property, such as ‘border-style’, was set to ‘none’ or
‘hidden’, the computed ‘*-width’, such as ‘border-width’,
would resolve to ‘0px’, even if the width was explicitly
set to ‘10px’. Following a resolution in the CSSWG [1],
the computed values of ‘border-width’, ‘outline-width’,
and ‘column-rule-width’ will now reflect their specified
values, regardless of the associated style property's
value. Similarly, the resolved values of ‘outline-width’,
and ‘column-rule-width’ will now reflect their specified
values, regardless of the associated style property's
value. [1]:
https://github.com/w3c/csswg-drafts/issues/11494#issuecomment-2675800489
<https://github.com/w3c/csswg-drafts/issues/11494#issuecomment-2675800489>
*Blink component*
Blink>CSS
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22>
*Web Feature ID*
/No information provided/
*Motivation*
Today, CSS special-cases ‘border-*-width’,
‘outline-width’, and ‘column-rule-width’ so that their
computed value becomes ‘0px’ when the corresponding
‘*-style’ is ‘none’ or ‘hidden’, even if the author
specified a nonzero width. With Gap Decorations extending
‘column-rule-*’ properties to support lists/repeaters,
applying that special-case becomes ambiguous and
difficult to define consistently. Having ‘*-width’ values
independent of ‘*-style’, provides an intuitive model for
these properties and better reflects the author-specified
value.
As a non-CSS expert, can you help me better understand
what "applying that special-case becomes ambiguous and
difficult to define consistently"? Is this in terms of
code that authors would write, or prose for spec authors?
An example would be helpful here.
*Initial public proposal*
https://github.com/w3c/csswg-drafts/issues/11494
<https://github.com/w3c/csswg-drafts/issues/11494>
*Search tags*
column-rule-width
<http:///features#tags:column-rule-width>, border-width
<http:///features#tags:border-width>, outline-width
<http:///features#tags:outline-width>
*TAG review*
/No information provided/
*TAG review status*
Not applicable
*Risks*
*Interoperability and Compatibility*
The interoperability risk is low as both Gecko and Webkit
have already implemented these changes. Compatibility
risk is also low. The resolved value for `border-width`
via `getComputedStyle()` will remain 0px when
`border-style` is set to `none`/ `hidden`, maintaining
backward compatibility. For `outline-width` and
`column-rule-width`, both computed and resolved values
will show the specified values, as these properties are
rarely queried and unlikely to impact existing content.
To support the claim, we collected UseCounter data
measuring how often these values are queried. The
computed‑value counters for these properties are
extremely low (<0.0001%). The resolved‑value counters for
‘column-rule-width’ and ‘outline-width’ show ~2.37%
usage, which reflects calls to ‘getComputedStyle()’
rather than observable rendering usage. Since
‘getComputedStyle()’ is frequently queried by automated
tooling (e.g. scrapers and fingerprinting scripts) that
do not depend on property semantics, this usage does not
indicate meaningful web‑facing reliance. As a result, the
compatibility risk remains low.
2.37% of page views is a lot of page views. Why do we feel
confident that border-width needs backwards compat
considerations for getComputedStyle but column-rule-width
and outline-width don't? Are you saying that 2.37% of the
use counters are coming from fingerprinting? I'm also not
sure what it means for a scraper to trigger a UseCounter -
can you clarify? I've typically thought of scraping as a
server-side operation - are these web extensions?
thanks!
/Gecko/:
Shipped/Shipping
(https://bugzilla.mozilla.org/show_bug.cgi?id=1998285
<https://bugzilla.mozilla.org/show_bug.cgi?id=1998285>)
/WebKit/:
Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=304940
<https://bugs.webkit.org/show_bug.cgi?id=304940>)
/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?
/No information provided/
*Debuggability*
No extra functionality is needed in Devtools to debug
this feature update.
*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
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
Yes
https://wpt.fyi/results/css/css-backgrounds/animations/border-width-interpolation.html
<https://wpt.fyi/results/css/css-backgrounds/animations/border-width-interpolation.html>
https://wpt.fyi/results/css/CSS2/ui/outline-width-096.xht
<https://wpt.fyi/results/css/CSS2/ui/outline-width-096.xht>
https://wpt.fyi/results/css/CSS2/borders/border-width-011.xht
<https://wpt.fyi/results/css/CSS2/borders/border-width-011.xht>
https://wpt.fyi/results/css/CSS2/borders/border-width-012.xht
<https://wpt.fyi/results/css/CSS2/borders/border-width-012.xht>
https://wpt.fyi/results/css/css-ui/parsing/outline-width-computed.html
<https://wpt.fyi/results/css/css-ui/parsing/outline-width-computed.html>
https://wpt.fyi/results/css/css-ui/outline-009.html
<https://wpt.fyi/results/css/css-ui/outline-009.html>
https://wpt.fyi/results/css/css-ui/animation/outline-width-interpolation.html
<https://wpt.fyi/results/css/css-ui/animation/outline-width-interpolation.html>
https://wpt.fyi/results/css/css-multicol/parsing/column-rule-width-computed.html
<https://wpt.fyi/results/css/css-multicol/parsing/column-rule-width-computed.html>
https://wpt.fyi/results/css/css-multicol/parsing/column-rule-computed.html
<https://wpt.fyi/results/css/css-multicol/parsing/column-rule-computed.html>
https://wpt.fyi/results/css/css-backgrounds/animations/border-width-interpolation.html
<https://wpt.fyi/results/css/css-backgrounds/animations/border-width-interpolation.html>
*Flag name on about://flags*
/No information provided/
*Finch feature name*
DecoupleComputedBorderWidthFromStyle,DecoupleResolvedColumnRuleWidthFromStyleEnabled
*Rollout plan*
Will ship enabled for all users
*Requires code in //chrome?*
False
*Tracking bug*
https://issues.chromium.org/issues/393631108
<https://issues.chromium.org/issues/393631108>
*Estimated milestones*
Shipping on desktop 146
Shipping on Android 146
Shipping on WebView 146
*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).
/No information provided/
*Link to entry on the Chrome Platform Status*
https://chromestatus.com/feature/5133099851317248?gate=5201902006173696
<https://chromestatus.com/feature/5133099851317248?gate=5201902006173696>
This intent message was generated by Chrome Platform
Status <https://chromestatus.com>.
--
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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69711ef3.710a0220.3080c5.02c3.GAE%40google.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69711ef3.710a0220.3080c5.02c3.GAE%40google.com?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cbe45224-f32d-41aa-851a-a050c272fc84n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cbe45224-f32d-41aa-851a-a050c272fc84n%40chromium.org?utm_medium=email&utm_source=footer>.
