[Intent to Prototype] Layout Instability Attribution in CSS Pixels

304 views
Skip to first unread message

Ane Diaz De Tuesta

unread,
Jul 22, 2025, 5:00:28 PM Jul 22
to blin...@chromium.org
Hi all,
I'd like to announce an Intent to Prototype for:

  • Feature name: Layout Instability Attribution in CSS Pixels
  • Contact: anediaz@gmail
  • Summary: The Layout Instability API currently reports attribution rectangles (`prevRect` and `currentRect`) in device pixels, which vary based on resolution and `devicePixelRatio`. This change proposes reporting them in CSS pixels for consistency with other layout and performance APIs.
  • Motivation: This will align attribution with other Web APIs, such as `getBoundingClientRect()` and make layout shift data easier to visualize, debug, and combine across devices and tools.
  • TAG review: Not yet requested
  • Risks: None known. This change only affects how attribution data is reported, and is gated behind a runtime flag.
  • Interoperability:
    • Mozilla: No signal
    • WebKit: No signal
  • Estimated milestones: N/A (this is a prototype only)
  • Footprint: This will be implemented behind a runtime flag.

This Intent is to begin prototyping the feature and gather feedback.

Thank you for your help and time.
Cheers,
Ane Diaz de Tuesta

Rick Byers

unread,
Jul 22, 2025, 5:45:39 PM Jul 22
to Ane Diaz De Tuesta, blin...@chromium.org, Michal Mocny (Google Docs), Steve Kobes
Sounds like a valuable improvement, thank you!

I see you're talking with @mmocny on the CL , that's great. I wonder if this was just an oversight in our initial design? Seems like a bug to me. Think we can just switch it (and put the change on the changelog ) without causing compat issues? Or might we need to give devs a way to opt-in to the new semantics?  mmocny@ is the expert here though, so I'm happy with whatever he wants to do.

Cheers,
   Rick

--
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 blink-dev+...@chromium.org .
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACBGQem%2BV6_UiLktmqwDCSXC3RJaMpmNm%3DSxv%2BH6%3DY4yCk5Msg%40mail.gmail.com .

Michal Mocny

unread,
Jul 23, 2025, 8:03:28 AM Jul 23
to Rick Byers, Ane Diaz De Tuesta, blin...@chromium.org, Michal Mocny (Google Docs), Steve Kobes
I do suspect this was more of an oversight than a specific decision, and feedback from developers seems to align with Ane Diaz: most are having to work around this.

However, there are clients out there who now depend on this and we are reaching out to see if it's less of a total headache to fix in place or provide some pathway for compat.  Because this is mostly used for logging / tooling and not for real time user experience, so far the feedback has been mostly that this would be fine to break and easy to fix -- but there are a few other consumers we want to get feedback from.

Ane Diaz De Tuesta

unread,
Jul 31, 2025, 6:52:39 AM Jul 31
to blink-dev, Michal Mocny, Ane Diaz De Tuesta, blin...@chromium.org, sko...@chromium.org, rby...@chromium.org

Hello,

It’s been about 10 days since I shared the Intent to Prototype proposal, and from what I gather, it has been generally well received.

As I’m not entirely familiar with the process, I’d like to suggest the following next steps—unless there are any objections:

  • Merge the CL

  • Update the feature status to “Prepare to ship”on ChromeStatus

  • Begin drafting the Intent to Shipemail

Please let me know if you agree with this approach, or if there’s anything else I should address before moving forward.

Thanks!

Daniel Bratell

unread,
Jul 31, 2025, 7:33:16 AM Jul 31
to Ane Diaz De Tuesta, blink-dev, Michal Mocny, sko...@chromium.org, rby...@chromium.org

I agree that it seems like a good idea, and the only concern would be whether it will break things. It sounds like Michal Mocny has been on top of things, but what were his findings?

Once it comes to the shipping decision, the more you can say about interoperability and compatibility, the better.

For compatibility between browsers, are there bug issues in the Mozilla and WebKit databases already? If not, it would be great if you could file some so that they end up making the same fix.

/Daniel

Ane Diaz De Tuesta

unread,
Aug 1, 2025, 5:23:13 AM Aug 1
to blink-dev, Daniel Bratell, Michal Mocny, sko...@chromium.org, rby...@chromium.org, Ane Diaz De Tuesta

Thanks, I completely agree, the more we can highlight interoperability and cross-browser compatibility, the better, especially as we move toward the Intent to Ship stage.

My plan is to go step by step: first land the fix, then progressively enable the flag, assuming that’s aligned with how we usually handle this in the Blink Intent process (this is my first time going through it, so I really appreciate the guidance).

Regarding compatibility bugs for Mozilla and WebKit, I can take a look at filing those after I return from vacation (I’ll be off for the next 3 weeks starting today). I’m not entirely sure how to approach that part, so any help on that front would be appreciated.


Excited to hear your thoughts, Michal Mocny.

/Ane

Rick Byers

unread,
Aug 1, 2025, 12:00:55 PM Aug 1
to Ane Diaz De Tuesta, blink-dev, Daniel Bratell, Michal Mocny, sko...@chromium.org
In terms of the process, yes we do just land CLs behind flags (off by default, potentially turned on by the enable-experimental-web-platform-features flag). No approval is needed here for that, just from code OWNERS reviewing the CL (probably Michal in this case, but could be others too if he's busy - should be low risk as long as the flag isn't on by default). 

In fact I think there's an argument that you don't need an I2S at all for this as a bug fix. But the compat risk is non-trivial enough that perhaps biasing in favor of the transparency and public discussion seems is a good idea. Michal, I don't think you've historically done an I2S for other metrics semantics tweaks in the changelog , right? Is this case any different and so worth doing an I2S for you think? I'm happy to defer to the metrics team judgement on this as the chance of any user-visible breaking change is IMHO near zero (close to that of any other blink bugfix). 

In terms of 'progressively enabling the flag', it's really a judgement call on how best to do that per feature. In this case I think I'd personally bias towards just deciding whether we think it's safe to turn on and then just enabling it 100% for a certain Chromium release. That way developers can at least compare the values to the Chrome version number if needed to determine the precise semantics. But we'd leave the flag there as a 'kill switch' we could flip if needed in the event of any serious breakage (and thereby end up breaking the correlation between version number and semantics unfortunately). Since this really does feel like a bug fix that shouldn't impact user-visible functionality, I think any process involving A/B testing is overkill (and also risks causing more confusion with developers than benefit). 

Thanks, have a great vacation!
   Rick


Ane Diaz De Tuesta

unread,
Aug 4, 2025, 10:57:14 AM Aug 4
to Rick Byers, blink-dev, Daniel Bratell, Michal Mocny, sko...@chromium.org
Thanks a lot for the clarifications!

Sounds good, I’ll wait for Michal’s input here, and if he’s unavailable, I’ll look for another code OWNER to approve the CL. By the way, in that case, what’s the recommended way to assign someone else as a reviewer?

I’m also aligned with the idea of being transparent and publicly surfacing the change. Just to double-check: you’re suggesting the need (or not) for an I2S really depends on whether the metrics team considers it to be a compat-affecting change that warrants mention in the changelog, right? That makes sense to me.

I like the proposal of enabling the flag by default starting with a specific Chrome version while keeping it as a kill-switch, just in case. For what it’s worth, my team will be impacted by this change in production — we currently use the layout-shift attribution data (previous + current rects) together with the DPR of the screen where the CLS was recorded to transform those rects into CSS pixels and overlay them on the DOM. Having a way to control when the new behavior kicks in will indeed be extremely helpful for us to roll out our internal changes safely.

Thanks again for your guidance and quick responses!☀️

Best regards,
Ane :-)

Michal Mocny

unread,
Aug 8, 2025, 1:21:32 PM Aug 8
to Ane Diaz De Tuesta, Rick Byers, blink-dev, Daniel Bratell, Michal Mocny, sko...@chromium.org
(Sorry, was OOO last week)

I think the CL is ready for landing (~few more small review comments and potential test updates).

The feature flag right now is marked for Origin Trial, but I don't think OT is a good fit for this change.  Instead we can set the feature as experimental, publicize the proposed change, clarify the spec (if needed), and then start a finch rollout process while watching for surprise feedback.  I can help walk through that process once this lands!

-Michal

Ane Diaz De Tuesta

unread,
Aug 8, 2025, 1:43:16 PM Aug 8
to Michal Mocny, Rick Byers, blink-dev, Daniel Bratell, sko...@chromium.org
Hello,
Thanks for your code review and your feedback!

I am currently on PTO until the last week of August, and I'll address your comments once I'm back.
Many of the issues in my patch stem from my lack of familiarity with the codebase, the libraries and the language, I really appreciate your guidance and the opportunity to learn so much.

I'll follow up with you in a few weeks :-)

Best regards,
Ane

Michal Mocny

unread,
Aug 8, 2025, 2:00:05 PM Aug 8
to Ane Diaz De Tuesta, Michal Mocny, Rick Byers, blink-dev, Daniel Bratell, sko...@chromium.org
Absolutely-- fantastic of you to put in the effort to contribute!  Enjoy your time off.

-Michal

Ane Diaz De Tuesta

unread,
Sep 2, 2025, 6:19:57 AM (5 days ago)  Sep 2
to blink-dev, Michal Mocny, rby...@chromium.org, blink-dev, Daniel Bratell, sko...@chromium.org, Ane Diaz De Tuesta

Hello,

I’ve addressed the comments on my review. As mentioned in one of them, I’ve had some difficulties running tests locally due to issues with my machine.

I think it would be best to run try jobs to identify any remaining modifications needed before the CL can be merged. Could you please run them for me, since I don’t have the rights to do so?


Thanks again for your help!

Reply all
Reply to author
Forward
0 new messages