Very cool, thanks for getting this fixed! On Tue, Jan 6, 2026 at 10:34 AM 'Michal Mocny' via blink-dev < [email protected]> wrote:
> Well done, thanks for the contribution! > > On Tue, Jan 6, 2026 at 10:09 AM Ane Diaz De Tuesta <[email protected]> > wrote: > >> Hi all, >> >> Thank you to *chrishtr@*, *miketaylr@*, and *yoavweiss@* for the LGTMs! >> (and *barryp@* for your guidance!) >> >> I'm happy to report that this feature has now shipped: >> ✅ All review gates completed (Privacy, Security, Enterprise, Testing, >> Debuggability) >> ✅ Flag CL merged: >> https://chromium-review.googlesource.com/c/chromium/src/+/7261417 >> ✅ CLS changelog updated >> ✅ Shipped in Chrome 145 >> >> The Layout Instability API now reports attribution rectangles in CSS >> pixels by default, improving consistency with other Web Platform APIs. >> >> Should I update the ChromeStatus page to reflect that all changes have >> been addressed? If yes, what fields should I update? >> > Nope, the Chromestatus entry <https://chromestatus.com/feature/5155103518228480> looks good and complete to me. Of course please keep your ears open for any issues which may arise prior to or around M145 hitting stable on Feb 10, and worst case be prepared to flip it off temporarily and update Chromestatus for the delay. But of course that's not likely to be necessary, so we don't require any chromestatus updates for the happy path of all going as planned. >> Thanks again to everyone who provided feedback and guidance throughout >> this process! >> >> Le lundi 5 janvier 2026 à 16:57:29 UTC+1, Ane Diaz De Tuesta a écrit : >> >>> 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/44922610-8f72-4c25-99a2-51ace64ce428n%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/44922610-8f72-4c25-99a2-51ace64ce428n%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/CAEeF2TcK67AJjq%2BHwm7cWVaKKY_O7YGqTr8a7OTFE7nzikb1Xg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEeF2TcK67AJjq%2BHwm7cWVaKKY_O7YGqTr8a7OTFE7nzikb1Xg%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/CAFUtAY-mOD48ek97dPrsWYJgx4pJns8MdM5qU%2B-u135q2VvJ6Q%40mail.gmail.com.
