Intent to Ship: Decouple border-width, outline-width and column-rule-width values from their corresponding style values

[Chromestatus]

Contact emails

samome...@microsoft.com, kbab...@microsoft.com

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

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.

Initial public proposal

https://github.com/w3c/csswg-drafts/issues/11494

Search tags

column-rule-width, border-width, 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.

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?

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.

[Mike Taylor]

On 1/21/26 1:46 p.m., Chromestatus wrote:

Contact emails

samome...@microsoft.com, kbab...@microsoft.com

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

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, border-width, 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!

--
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/69711ef3.710a0220.3080c5.02c3.GAE%40google.com.

[Sam Davis Omekara]

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.
    • + ikilp...@google.com for more details on this.

[Alex Russell]

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

[Vladimir Levin]

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

[Daniel Bratell]

LGTM2, with the plan outlined by Vlad.

/Daniel

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cbe45224-f32d-41aa-851a-a050c272fc84n%40chromium.org.

[Sam Davis Omekara]

After taking a closer look into the UMA, I realized that the use counter was not measuring active and intentional usage of these properties. Instead, it largely captures cases when an element’s resolved css values are retrieved (most commonly via `getComputedStyle()`, also via opening dev tools). 

Because the default width values are non-zero (medium) and their corresponding style’s default is none, the counter can fire even when authors never explicitly set these or retrieve these properties. This happens because `getComputedStyle()` requests/serializes styles for all properties on the element, not just the one an author may care about. As a result, the ~2.37% figure can be treated as a very high upper bound on potential exposure rather than a granular measurement of these specific properties. 

Unfortunately, with the current setup it is not trivial to architect a use counter that measures only when developers meaningfully use these properties as opposed to incidental serialization during style queries. To get some directional signal, I manually surveyed the top 10 sites that the counter fired for and did not find any that were doing anything special with these properties.

That said, each behavior change (for the computed and for the resolved) is guarded by its own finch feature flag, which provides a reliable rollout plan and kill switch if we observe unexpected impact on developers.

[Ian Kilpatrick]

> follow a finch rollout that propagates the feature to the stable channel slowly

For this type of change this risks more confusion/breakage to web-developers & users vs. just letting it roll out via the normal stable ramp and using the kill-switch if needed.

Previously we've had issues where we've tried to roll out web-platform changes like this via finch, and it has caused more trouble than its worth.

(E.g. Previously when we've tried to roll things out incrementally, it led to web developers not reporting issues, as they thought it was some transient issue caused by an extension of similar. This leaks to a longer breakage for end-users vs. if the bug was reported immediately).

non-owner lgtm FWIW, but just with a kill-switch type rollout.

Ian

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/75fdee9a-7382-4520-8da0-4b96087dfe37n%40chromium.org.

[Vladimir Levin]

On Thu, Feb 5, 2026 at 9:03 AM Ian Kilpatrick <ikilp...@chromium.org> wrote:

> follow a finch rollout that propagates the feature to the stable channel slowly

For this type of change this risks more confusion/breakage to web-developers & users vs. just letting it roll out via the normal stable ramp and using the kill-switch if needed.

Previously we've had issues where we've tried to roll out web-platform changes like this via finch, and it has caused more trouble than its worth.

(E.g. Previously when we've tried to roll things out incrementally, it led to web developers not reporting issues, as they thought it was some transient issue caused by an extension of similar. This leaks to a longer breakage for end-users vs. if the bug was reported immediately).

non-owner lgtm FWIW, but just with a kill-switch type rollout.

I'm talking about something on the order of a week at 1%, a week at 10% and then moving to 100%, which is still pretty fast. I guess this feature doesn't affect things like performance or metrics, so there's nothing to compare to other than "there are no bug reports". Kill-switch roll out also sounds fine to me.

Thanks,

Vlad

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJL3UpS-QNB1MAPXDroM9TrAn6EPhPWes4pa%3DSc%2BYHLdgqRmhw%40mail.gmail.com.