[Intent to Prototype] Layout Instability Attribution in CSS Pixels

[Ane Diaz De Tuesta]

Hi all,
I'd like to announce an Intent to Prototype for:

• Feature name: Layout Instability Attribution in CSS Pixels

• Contact: anediaz@gmail

• Explainer: https://github.com/anediaz/layout-shift-attribution-in-css-pixels/blob/main/Explainer.md

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

• Initial public proposal: https://issues.chromium.org/issues/399058544

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

• Link to entry on Chrome Platform Status: https://chromestatus.com/feature/5155103518228480

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]

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]

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]

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 Ship email

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]

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

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/15ac55eb-46bc-44d4-b50b-517d21fb27een%40chromium.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]

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]

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]

(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]

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]

Absolutely-- fantastic of you to put in the effort to contribute!  Enjoy your time off.

-Michal

[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!

[Ane Diaz De Tuesta]

Hello,

I addressed last feedback and all try-jobs are now passing 🎉

As mentioned in my last comment in the CL, I attempted to add tests for the null widget case, but it turned out to be quite tricky to simulate.

I’d prefer to keep the current changes as-is and move forward with merging this CL.

Do you think it’s reasonable to proceed with landing this patchset?

On a related note, regarding the Element Timing issue we discussed earlier, what would you recommend as the best next step?

Should I file a bug first, or go ahead and send a CL with the fix directly?

Thanks again :-)

Ane

[Ane Diaz De Tuesta]

Hi everyone,

I recently merged the patch for Layout Instability Attribution in CSS Pixels (merged on Oct 8) and would now like to begin the first “Intent to Ship” step, testing the feature locally.

I’ve installed Chrome Dev 143.x, where the patch should already be included (confirmed via the “Included in” tags on Gerrit). However, I’m currently unable to find the new flag I added — ReportLayoutShiftRectsInCssPixels — under chrome://flags. This flag is required to test the expected behavior locally.

Could anyone advise on how to proceed?

• Do I need to enable a specific runtime flag or Finch experiment to activate the feature?

• Is there a build configuration or command-line flag I should use to ensure the patch is active for local testing?

• Are there additional steps I should take before starting the “Intent to Ship” verification phase?

Any guidance or pointers would be greatly appreciated.

Thanks,
Ane

[Michal Mocny]

On Tue, Oct 28, 2025 at 9:23 AM Ane Diaz De Tuesta <ane...@gmail.com> wrote:

Hi everyone,

I recently merged the patch for Layout Instability Attribution in CSS Pixels (merged on Oct 8) and would now like to begin the first “Intent to Ship” step, testing the feature locally.

I’ve installed Chrome Dev 143.x, where the patch should already be included (confirmed via the “Included in” tags on Gerrit). However, I’m currently unable to find the new flag I added — ReportLayoutShiftRectsInCssPixels — under chrome://flags. This flag is required to test the expected behavior locally.

Chrome://flags need to be explicitly added to the UI, and are distinct from feature flags which you can control with command line arguments, and 

Could anyone advise on how to proceed?

• Do I need to enable a specific runtime flag or Finch experiment to activate the feature?

I would follow this guide for explicitly enabling this flag for yourself locally (Just use --enable-blink-features=).  One note to be careful about: if you try to launch a Chrome process which is already open (i.e. your stable browser) it will merely open a new window with the same process and will NOT apply new flags from the command line.  Ensure you are starting a new browser instance.  I like to use Canary (or a custom build), but you can also pass a distinct --user-data-dir="<path_to_directory>" as an alternative.

Regarding Finch-- this is a mechanism to enable the flag in the field for real users-- but as a public web platform api change (...albeit a minimal one), this should not roll out with the finch process.  Instead you can go straight to launch after manual testing (sounds like we need more of this first).

• Is there a build configuration or command-line flag I should use to ensure the patch is active for local testing?

• Are there additional steps I should take before starting the “Intent to Ship” verification phase?

I would review this step and then this step.

You did discuss this with developers, but I might suggest signalling (Web Perf Slack?) that it is ready for testing, with instructions on how to try it.  I would also confirm if the spec wording needs a change (maybe not, maybe the previous behaviour was not compliant and now is).

Overall, I don't think there needs to be much more process before moving the feature forward.