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