LGTM3 w/ kill switch for rollout. On Thursday, February 5, 2026 at 7:16:08 AM UTC-8 Vladimir Levin wrote:
> 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/5dea894d-f0be-45a4-baa5-0ae04a423fabn%40chromium.org.
