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.
- 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;
- This cycles to: “1px solid, 2px dashed, (1px) none, 2px solid, 1px
dashed, (2px) none …”.
- Setting the width to zero in this case depending on the style at
any point in the expansion isn’t well-defined.
- 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;
- 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?
- 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.
- 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
>
> *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
>
> *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
>
> *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)
>
> *WebKit*: Shipped/Shipping (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/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-012.xht
> 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/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-computed.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
>
> *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
>
> 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/bbb9af14-4d90-4a0f-a6dd-60f97f274279n%40chromium.org.
