(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 On Mon, Aug 4, 2025 at 7:56 AM Ane Diaz De Tuesta <aned...@gmail.com> wrote: > 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/CAEeF2Te0CdXDhu8KgqiAVjfGRukuRWaf4KFc6ai_bUP4c1P9Kw%40mail.gmail.com.
