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/CAFUtAY_zZ6pg8Oao_%2Bdo1PRv-dpQU6%3Dri9K%3Dp_xNAWMW%2BUx-cQ%40mail.gmail.com.
