On Mon, Dec 15, 2025 at 1:55 PM Ane Diaz De Tuesta <[email protected]> wrote:
> Thanks for your +1s! > > I've just triggered the missing gates (Testing and Privacy). Once those > are approved, I understand the next steps are: > > 1. Create a follow-up CL to enable the feature by default and get it > reviewed and merged before the M145 branch point > Indeed. The "merge" part needs to only happen after all the gates are nice and green (Enterprise, Testing and Debuggability approved, and you got two more API owners to approve this intent). > 2. Update the ChromeStatus entry to reflect "Enabled by default" status > Yup. It would also be nice to make sure that MDN and other relevant docs get updated with the up-to-date unit. Given that this is a breaking change, it may make sense to also include it in some release notes. +Barry Pollard <[email protected]> would most probably know where that may be. > > Please let me know if there are any additional steps or if I should wait > for further guidance before creating the enablement CL. > No need to wait before creating the CL, just before merging it. > > > Best, > Ane > > Le lundi 15 décembre 2025 à 10:54:55 UTC+1, [email protected] a écrit : > >> [email protected] - can you flip the review bits for Enterprise, >> Debuggability and Testing? >> >> On Mon, Dec 15, 2025 at 10:53 AM Yoav Weiss (@Shopify) < >> [email protected]> wrote: >> >>> LGTM1 >>> >>> The main risk here is for tools that get their input from this data and >>> visualize it to users (where the data can be in either synthetic or RUM). >>> We mainly care about RUM data here, but even there, the direct compat risk >>> for actual users is minimal. In other words, this change will not create >>> visible breakage for users, but may create one for developers that use >>> tools that rely on this data. >>> >>> On Mon, Dec 15, 2025 at 10:20 AM 'Barry Pollard' via blink-dev < >>> [email protected]> wrote: >>> >>>> Not that I've discussed this previously with Ane and this may require >>>> changes to those tools using these pixels to create screenshots or >>>> animations of CLS. I've reached out directly to the primary tools I'm aware >>>> off in this space (Chrome DevTools, DebugBear, WebPageTest) as well as more >>>> general outreach on the likes of the Web Performance slack. Will continue >>>> that further now the I2S is published. >>> >>> >>> Thanks for the outreach! >>> >>> >>>> >>>> It's a small change to accommodate this change, is not critical (the >>>> worst case is the wrong area of the screenshot/animation will be >>>> highlighted until the change is made) and brings the Layout Instability API >>>> inline with other Web Platform APIs and most would expect of this. So I'm >>>> supportive of this change, despite this risk. >>>> >>>> Thanks, >>>> Barry >>>> >>>> On Friday, December 12, 2025 at 6:57:20 PM UTC [email protected] wrote: >>>> >>>>> # Contact emails >>>>> >>>>> [email protected] >>>>> >>>>> # Explainer >>>>> >>>>> None (This is a small compatibility fix - the spec PR serves as the >>>>> explainer). >>>>> The PR is a spec change, not an explainer. You can say "None" or link >>>>> to a separate explainer if you have one. >>>>> >>>>> # Specification >>>>> >>>>> https://wicg.github.io/layout-instability/ >>>>> >>>>> # Summary >>>>> >>>>> Change Layout Instability API attribution rectangles (`prevRect` and >>>>> `currentRect`) from device pixels to CSS pixels. This aligns the API >>>>> with other Web Platform measurement APIs (getBoundingClientRect, >>>>> IntersectionObserver, ResizeObserver) that use CSS pixels as the standard >>>>> coordinate system. >>>>> >>>>> # Blink component >>>>> >>>>> Blink>PerformanceAPIs >>>>> >>>>> # Motivation >>>>> >>>>> The current implementation uses device pixels, which: >>>>> - Creates inconsistencies across devices with different pixel ratios >>>>> - Makes it difficult for developers to correlate layout shift data >>>>> with other measurements >>>>> - Deviates from the standard coordinate system used throughout the >>>>> web platform >>>>> >>>>> CSS pixels provide a consistent, device-independent unit that aligns >>>>> with developer expectations and simplifies working with layout >>>>> stability metrics alongside other DOM measurements. >>>>> >>>>> # TAG review >>>>> Not applicable - This is a small compatibility fix to an existing API, >>>>> not a new feature. The change aligns Layout Instability API attribution >>>>> rectangles with the standard CSS pixel coordinate system used by other Web >>>>> Platform APIs. This does not introduce new API surface or capabilities. >>>>> >>>>> # TAG review status >>>>> Not applicable >>>>> >>>>> # Chromium bug >>>>> https://issues.chromium.org/issues/399058544 >>>>> >>>>> # Risks >>>>> >>>>> ## Interoperability and Compatibility >>>>> >>>>> **Interoperability risk:** Low. This is a measurement/telemetry >>>>> change that doesn't affect site functionality. The API is used >>>>> primarily by monitoring/analytics tools. >>>>> >>>>> **Gecko:** Closed without a position ( >>>>> https://github.com/mozilla/standards-positions/issues/1318) - Mozilla >>>>> supports CSS pixels for web APIs, though they don't implement the Layout >>>>> Instability API. >>>>> >>>>> **WebKit:** No signal ( >>>>> https://github.com/WebKit/standards-positions/issues/588) >>>>> >>>>> **Web developers:** Positive feedback from WebPerf Slack community. >>>>> The change simplifies working with layout stability metrics. >>>>> >>>>> **Compatibility risk:** Low. Primary consumers are telemetry systems >>>>> (RUM providers, analytics tools) that can adapt their processing. The >>>>> change provides more consistent, useful data. Sites using the API >>>>> directly will see coordinate values change but can easily adapt by >>>>> removing device pixel ratio conversions. >>>>> >>>>> **Rollback plan:** Feature can be disabled via flag if unexpected >>>>> issues arise. >>>>> >>>>> # Ergonomics >>>>> >>>>> This change improves ergonomics by aligning with the CSS pixel >>>>> coordinate system developers already use in other APIs >>>>> (getBoundingClientRect, IntersectionObserver, ResizeObserver), reducing >>>>> confusion and simplifying debugging. >>>>> >>>>> # Activation >>>>> >>>>> No user activation required - this is a measurement/telemetry API. >>>>> >>>>> # Security >>>>> >>>>> No security concerns - this changes the unit of measurement for >>>>> existing data, does not expose new information. >>>>> >>>>> # WebView application risks >>>>> >>>>> None. This is a measurement/telemetry change that works consistently >>>>> across all platforms including WebView. >>>>> >>>>> # Debuggability >>>>> >>>>> No changes to debuggability. The API continues to work the same way, >>>>> just with CSS pixel coordinates instead of device pixels. >>>>> >>>>> # 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. Web Platform Tests have been updated to verify CSS pixel behavior >>>>> for attribution rectangles. >>>>> >>>>> WPT link: >>>>> https://wpt.fyi/results/layout-instability/attribution-rectangles-css-pixels.html >>>>> >>>>> # Flag name on chrome://flags >>>>> >>>>> None (controlled by base::Feature) >>>>> >>>>> # Finch feature name >>>>> >>>>> None - shipping enabled by default for all users. This is a low-risk >>>>> compatibility fix to a measurement API with good test coverage. >>>>> >>>>> # Non-Finch justification >>>>> >>>>> This is a compatibility fix to align the Layout Instability API with >>>>> standard Web Platform coordinate systems. The change affects measurement >>>>> data rather than user-facing functionality, and has low risk of breakage. >>>>> Primary consumers are RUM/analytics tools that can adapt to the change. >>>>> >>>>> >>>>> # Requires code in //chrome? >>>>> >>>>> No. >>>>> >>>>> # Estimated milestones >>>>> >>>>> Shipping on desktop: 145 >>>>> Shipping on Android: 145 >>>>> >>>>> # Spec changes >>>>> >>>>> Spec PR merged: https://github.com/WICG/layout-instability/pull/125 >>>>> (Clarifies that attribution rectangles use CSS pixels, consistent with >>>>> other Web Platform APIs) >>>>> >>>>> # Link to entry on the Chrome Platform Status >>>>> >>>>> https://chromestatus.com/feature/5155103518228480 >>>>> >>>>> # Links to previous Intent discussions >>>>> >>>>> Intent to Prototype: >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/EMlUrEwx_uE/m/pxBix6wWDAAJ?utm_medium=email&utm_source=footer >>>>> >>>>> --- >>>>> >>>>> **This intent message was generated by Chrome Platform Status.** >>>>> >>>>> Security and Privacy reviews have been approved via ChromeStatus gates. >>>>> >>>>> Implementation CL: >>>>> https://chromium-review.googlesource.com/c/chromium/src/+/6624567 >>>>> >>>>> --- >>>>> >>>> -- >>>> 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/1a72af4d-f574-488a-913e-a98135d3afban%40chromium.org >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1a72af4d-f574-488a-913e-a98135d3afban%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/CAOmohS%2BCfRO1yGC7AZOZPhsrvhqemK-BvS6BUe8MSoTKmWqRXw%40mail.gmail.com.
