On Thu, Feb 5, 2026 at 9:03 AM Ian Kilpatrick <[email protected]> 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 > Ian > > On Thu, Feb 5, 2026 at 12:28 AM 'Sam Davis Omekara' via blink-dev < > [email protected]> wrote: > >> 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. >> >> On Wednesday, February 4, 2026 at 8:24:06 AM UTC-8 Daniel Bratell wrote: >> >>> LGTM2, with the plan outlined by Vlad. >>> >>> /Daniel >>> On 2026-02-04 17:16, Vladimir Levin wrote: >>> >>> 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. >>>>> - 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/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> >>> . >>> >>> -- >> 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/75fdee9a-7382-4520-8da0-4b96087dfe37n%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/75fdee9a-7382-4520-8da0-4b96087dfe37n%40chromium.org?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/CAJL3UpS-QNB1MAPXDroM9TrAn6EPhPWes4pa%3DSc%2BYHLdgqRmhw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJL3UpS-QNB1MAPXDroM9TrAn6EPhPWes4pa%3DSc%2BYHLdgqRmhw%40mail.gmail.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/CADsXd2PHKexT_%3DbZUGz0kkhhoGAWuo17HhvML5m5g1go-c320A%40mail.gmail.com.
