This is amazing — thank you both! Since all the gates are approved, the final step to ship the feature is to merge the CL that promotes ReportLayoutShiftRectsInCssPixels to stable: https://chromium-review.googlesource.com/c/chromium/src/+/7261417
Mike, I added you as the code owner, since you’ve been incredibly helpful throughout this process. I can’t believe I’ll see this live soon 🤩 — my Christmas gift *after* Christmas 🙂 Thank you! Le lundi 5 janvier 2026 à 16:47:17 UTC+1, [email protected] a écrit : > Thanks Mike! I was just chasing the Chrome Tooling team on this to see if > anyone else could approve in his absence. They're aware of the change and > have been liaising with Ane on it. So good to approve. > > On Mon, 5 Jan 2026 at 15:41, Mike Taylor <[email protected]> wrote: > >> Hi Ane, >> >> The debuggability reviewer is OOO for the next week or so, but based on >> your answers I've gone ahead and approved the bit. >> >> thanks, >> Mike >> On 12/30/25 4:34 a.m., Ane Diaz De Tuesta wrote: >> >> Hi all, >> >> I'm following up on the Debuggability gate, which is currently showing as >> overdue by a day on ChromeStatus. I'd like to move forward with completing >> the Intent to Ship process. >> >> For context, this change modifies Layout Instability API attribution >> rectangles from device pixels to CSS pixels, a units change that aligns >> with other Web Platform APIs (getBoundingClientRect, IntersectionObserver, >> etc.). >> >> From a debuggability perspective: >> >> - The API continues to work identically, just reporting CSS pixels >> instead of device pixels >> - DevTools Layout Instability tracking remains unchanged >> - Developers can inspect the values the same way through the >> PerformanceObserver API >> >> If there are specific debuggability concerns or additional information >> needed, I'm happy to provide it. Otherwise, any guidance on how to move >> this gate forward would be greatly appreciated. >> >> Thanks! >> Ane :-) >> Le mercredi 17 décembre 2025 à 16:04:31 UTC+1, Chris Harrelson a écrit : >> >>> LGTM3 >>> >>> On Tue, Dec 16, 2025 at 6:38 AM Mike Taylor <[email protected]> >>> wrote: >>> >>>> This intent is visible in the API Owner review queue, so no need to >>>> ping (unless the thread goes silent for a ~week). >>>> On 12/16/25 8:06 a.m., Ane Diaz De Tuesta wrote: >>>> >>>> As discussed with Barry Pollard offline, in all web docs we assume that >>>> pixels = CSS pixels! >>>> When it's physical pixels that should be the exception that's >>>> documented. >>>> >>>> So after a second reflection, we finally got back to the conclusion >>>> that MDN doesn't need to be updated. >>>> >>>> Now, I am looking for my last API Owner approval, can I ping someone or >>>> approvers will show naturally? >>>> >>>> >>>> Thanks! >>>> Best, >>>> Ane >>>> >>>> Le mardi 16 décembre 2025 à 01:54:18 UTC+1, [email protected] a >>>> écrit : >>>> >>>>> LGTM2 (and thanks Barry for doing outreach to RUM providers). >>>>> On 12/15/25 4:53 a.m., Yoav Weiss (@Shopify) 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/CAOmohSKPSqnxw8PAizjj%3DT9yPLWMobxv3BOgJ7J-MEkD0_qB0w%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKPSqnxw8PAizjj%3DT9yPLWMobxv3BOgJ7J-MEkD0_qB0w%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/159d7198-045f-46a8-b1e9-a0f8a85c06fe%40chromium.org >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/159d7198-045f-46a8-b1e9-a0f8a85c06fe%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/62242494-53b5-49ba-b1ac-76c3edfcf07fn%40chromium.org.
