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/CAOMQ%2Bw8nQKX04tJF5_qzTZwPWTBHSRXn%3DN_oDZu_byi9Wqxrqw%40mail.gmail.com.
