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
<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/c39ce62e-0241-4ec0-af6c-491adb68db6f%40chromium.org.
