Intent to Ship: Layout Instability API CSS Pixel Attribution

37 views
Skip to first unread message

Ane Diaz De Tuesta

unread,
Dec 12, 2025, 1:57:20 PM (15 hours ago) Dec 12
to blink-dev
# Contact emails


# 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


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


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


# 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


# Links to previous Intent discussions


---

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

---
Reply all
Reply to author
Forward
0 new messages