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 :-) On Fri 1 Aug 2025 at 18:00, Rick Byers <rby...@chromium.org> wrote: > 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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/speed/metrics_changelog/README.md>, > 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 > > > > On Fri, Aug 1, 2025 at 2:43 AM Ane Diaz De Tuesta <aned...@gmail.com> > wrote: > >> 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 >> >> Le jeudi 31 juillet 2025 à 13:33:16 UTC+2, Daniel Bratell a écrit : >> >>> 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 >>> On 2025-07-31 08:17, Ane Diaz De Tuesta wrote: >>> >>> 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! >>> Le mercredi 23 juillet 2025 à 14:03:28 UTC+2, Michal Mocny a écrit : >>> >>>> 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. >>>> >>>> On Tue, Jul 22, 2025 at 5:45 PM Rick Byers <rby...@chromium.org> wrote: >>>> >>>>> Sounds like a valuable improvement, thank you! >>>>> >>>>> I see you're talking with @mmocny on the CL >>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/6624567>, >>>>> 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 >>>>> <https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/speed/metrics_changelog/cls.md>) >>>>> 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 >>>>> >>>>> On Tue, Jul 22, 2025 at 5:00 PM Ane Diaz De Tuesta <ane...@gmail.com> >>>>> wrote: >>>>> >>>>>> 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 >>>>>> -- >>>>>> 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 >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACBGQem%2BV6_UiLktmqwDCSXC3RJaMpmNm%3DSxv%2BH6%3DY4yCk5Msg%40mail.gmail.com?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 blink-dev+...@chromium.org. >>> >>> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/15ac55eb-46bc-44d4-b50b-517d21fb27een%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/15ac55eb-46bc-44d4-b50b-517d21fb27een%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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACBGQekSPhRfkBWyn917%2BNMuqYju9J4yY5EGoRSZV-jyJ8%2BjhQ%40mail.gmail.com.
