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>.
