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! Le vendredi 8 août 2025 à 20:00:05 UTC+2, Michal Mocny a écrit : > Absolutely-- fantastic of you to put in the effort to contribute! Enjoy > your time off. > > -Michal > > On Fri, Aug 8, 2025 at 1:43 PM Ane Diaz De Tuesta <[email protected]> > wrote: > >> 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 >> >> On Fri 8 Aug 2025 at 19:21, Michal Mocny <[email protected]> wrote: >> >>> (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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>>>> 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 < >>>>>>>>> [email protected]> 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 [email protected]. >>>>>>>>>> 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 [email protected]. >>>>>>> >>>>>>> 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b2cd05e1-b568-4b75-9e97-45ccf5fb271en%40chromium.org.
