[email protected] <[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/CAOmohSKSCoebYFpVg3T-GYQPjET1eW-2WCXDCgkfDYYAAVgLTQ%40mail.gmail.com.
