LGTM3 On Mon, Sep 12, 2022 at 4:32 PM Khushal Sagar <[email protected]> wrote:
> > > On Mon, Sep 12, 2022 at 4:59 AM Andre Bandarra <[email protected]> > wrote: > >> CC @Cheney Tsai <[email protected]>, @Una Kravets >> <[email protected]>, @Kadir Topal <[email protected]> >> >> From a DevRel perspective, the three questions in my mind are: >> >> - Are affected developers aware of the change? >> - I understand they were notified via a console warning / >> deprecation warning. It'd be great to get a sense of how effective the >> communication was (ie: has usage significantly decreased since the >> warnings?). >> >> M105 stable rollout started around August 30th so it's been less than a > couple of weeks. The UMA for tracking usage of overflow:visible on these > elements is here > <https://uma.googleplex.com/p/chrome/timeline_v2?sid=8c9729c3d3cbd34802a511a89abeb22e> > and > there hasn't been any change. Note that this is higher than the use counter > since it tracks whether the element had a style that could cause overflow, > not whether it actually painted with overflow. > >> >> - Have we given them enough time for developers to react to the >> change? >> - This is less about how complex a change is and more about >> ensuring developers can fit the change into their planning cycle (eg: >> quarterly OKRs) and avoiding generating unplanned/urgent work, if >> possible. >> It does seem to me the timelines described are short. >> >> Do you have a suggestion for an appropriate time to wait after the email > notification to sites we discovered via CT? Given the use counter for > significant breakage is low (~0.006%), I was hoping 6 weeks targeting M107 > would suffice. But we can push it out until M108 which gives it 10 weeks if > needed. > >> >> - Are developers somehow blocked in implementing the change? >> - The change seems quite straightforward, but sometimes developers >> are blocked in surprising ways. Is there a channel developers can >> provide >> feedback on? >> >> The email notification directs developers to the chromium issue tracker. > That'll help in documenting a fix for any unforeseen issues and redirecting > developers in case we receive duplicate bugs. > >> >> - >> >> Andre >> >> On Mon, 12 Sept 2022 at 01:54, Mike Taylor <[email protected]> >> wrote: >> >>> LGTM2 >>> >>> On 9/9/22 12:16 PM, Khushal Sagar wrote: >>> >>> >>> >>> On Fri, Sep 9, 2022 at 11:37 AM Yoav Weiss <[email protected]> >>> wrote: >>> >>>> Thanks for meticulously gathering that data!! >>>> >>>> Just to give a rough idea - 5K pixels would be 50x100 pixels, which >>>> is noticeable breakage but not necessarily an insurmountable one. >>>> The numbers are a bit higher than I'd like, but at the same time, this >>>> enables new capabilities and we're not walking this path alone >>>> <https://github.com/mozilla/standards-positions/issues/659#issuecomment-1182596173> >>>> . >>>> >>>> Given the above, *LGTM1* for a careful and monitored rollout, >>>> accompanied with DevRel folks supporting y'all in communicating this change >>>> to developers. >>>> What are the timelines you have in mind? Is there some way to use >>>> Deprecation Reporting to help us here? >>>> >>> >>> I would target a gradual roll out: 1% -> 10% -> 25% -> 50% -> 100% with >>> a week before each progression in M107. The release will go to stable >>> ~October 25th (schedule <https://chromiumdash.appspot.com/schedule>). >>> >>> In terms of outreach a console warning >>> <https://chromiumdash.appspot.com/commit/97b80f4e3b9b742a8c44fa5cb96b6c753b29f3d2> >>> and a deprecation warning >>> <https://chromiumdash.appspot.com/commit/0d0d8e0a1862e689690a702a5c5295531d9a3a27> >>> was >>> added in M105 for cases where the element's computed style can cause this >>> behaviour change. I've also reached out to the dev rel folks for a targeted >>> email to affected sites that came up through our CT analysis. >>> >>> >>>> >>>> On Fri, Sep 9, 2022 at 5:27 PM Khushal Sagar <[email protected]> >>>> wrote: >>>> >>>>> We have UseCounter data from M105 stable to quantify the large >>>>> breakage for this feature. Large is a page load where any image, video or >>>>> canvas drawn on the page paints over 5k CSS pixels outside its >>>>> content-box. >>>>> The precise numbers (with page load count) are here >>>>> <https://docs.google.com/document/d/1GC2wanCPtoboSujQVr5xoCDlpzzhspr0PHA-OBgGbEY/edit> >>>>> (sorry >>>>> can't share the details externally). >>>>> >>>>> In terms of percentage, Windows/Mac had ~0.006% page loads fall in the >>>>> large breakage category and Android had ~0.007%. >>>>> >>>>> On Tue, Aug 2, 2022 at 3:14 PM Khushal Sagar < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Mon, Aug 1, 2022 at 12:11 PM Yoav Weiss <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Jul 25, 2022 at 7:44 PM Khushal Sagar < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jul 20, 2022 at 5:17 AM Yoav Weiss <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Thanks Khushal! :) >>>>>>>>> >>>>>>>>> The breakage seems potentially significant (at worst, makes the >>>>>>>>> site visually broken and unusable), and the percentage of breakage >>>>>>>>> seems >>>>>>>>> above the threshold we typically consider safe. >>>>>>>>> At the same time this seems like a positive change, and our >>>>>>>>> friends at Mozilla consider it "worth prototyping". >>>>>>>>> >>>>>>>>> Would it be possible to consider this as a deprecation of the old >>>>>>>>> behavior, and run the console issue (+deprecation warnings and >>>>>>>>> outreach to >>>>>>>>> affected sites) for a few milestones, to try and drive the usage down >>>>>>>>> before flipping this change to be on by default? Maybe also get some >>>>>>>>> documentation out there and work with devrel folks to make sure folks >>>>>>>>> are >>>>>>>>> aware of this coming change? >>>>>>>>> >>>>>>>>> Does that sound reasonable? >>>>>>>>> >>>>>>>> >>>>>>>> Thanks for the suggestion Yoav. This sounds reasonable. I've >>>>>>>> reached out to the devrel folks to do more outreach about this change. >>>>>>>> I'll >>>>>>>> update this thread with the plan for it. The console issue and >>>>>>>> deprecation >>>>>>>> warnings have been added in M105. >>>>>>>> >>>>>>>> I looked into adding a use counter for sites which have real >>>>>>>> breakage, since the current metric tracks whether the computed style >>>>>>>> *could* permit allow but not whether there is actual overflow at paint >>>>>>>> time. And unfortunately computing potential overflow is not easy to >>>>>>>> add. >>>>>>>> The CT analysis I ran earlier did this by turning the feature on and >>>>>>>> tracking actual overflow generated by the element. So a couple of >>>>>>>> questions >>>>>>>> for moving forward: >>>>>>>> >>>>>>>> - Would it be okay to turn the feature on in beta and 1% stable (in >>>>>>>> M105) to collect metrics for the sites with real breakage and the >>>>>>>> extent of >>>>>>>> this breakage (how many pixels of overflow do we see). This should be >>>>>>>> lower >>>>>>>> than the counter of 0.017%. >>>>>>>> >>>>>>> >>>>>>> That sounds like a great way to gather data! (assuming the relevant >>>>>>> Chrome processes are followed) >>>>>>> Would be good to gather a histogram of overflowed pixels, to get a >>>>>>> sense of "small breakage" vs. "large breakage". >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> - What's the number (in terms of page loads affected) we should be >>>>>>>> targeting before this would be safe? >>>>>>>> >>>>>>> >>>>>>> From my perspective, I'd be comfortable shipping this if we're >>>>>>> seeing less than 0.003% of page loads in the "large breakage" bucket >>>>>>> (say >>>>>>> more than ~5000 overflowing pixels, assuming that number makes sense). >>>>>>> >>>>>>> +Andre Bandarra <[email protected]> - for devrel opinions on this. >>>>>>> >>>>>> >>>>>> Currently we're recording a UseCounter when any breakage would >>>>>> happen, i.e, there is any pixel overflow. If it helps to have a >>>>>> UseCounter >>>>>> for overflow above a threshold, I'm happy to add that too. >>>>>> >>>>>> We do have an UMA metric which measures the number of overflowing >>>>>> pixels when there is overflow but it's for all images rendered. I can tie >>>>>> it to the UseCounter so we can also know the number of affected page >>>>>> loads >>>>>> with large breakage. I'll wait till the end of the week for more >>>>>> feedback, >>>>>> otherwise assume 5k is a good threshold for large breakage. >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Yoav >>>>>>>>> >>>>>>>>> On Thursday, July 14, 2022 at 5:03:54 PM UTC+2 Khushal Sagar wrote: >>>>>>>>> >>>>>>>>>> Hey folks, >>>>>>>>>> >>>>>>>>>> I'm summarizing the steps to mitigate the compat risk with this >>>>>>>>>> feature based on the feedback: >>>>>>>>>> >>>>>>>>>> - Add a warning to the console when a developer style would >>>>>>>>>> permit replaced elements to overflow. The patch to add that is >>>>>>>>>> here >>>>>>>>>> >>>>>>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/3763640> >>>>>>>>>> and >>>>>>>>>> documentation to help developers debug, which is referenced in >>>>>>>>>> the console >>>>>>>>>> warning, is here >>>>>>>>>> >>>>>>>>>> <https://github.com/WICG/shared-element-transitions/pull/166/files>. >>>>>>>>>> We can pre-emptively add this warning to M105 and ship the >>>>>>>>>> feature in M106 >>>>>>>>>> to have a one release window before the behaviour changes. >>>>>>>>>> >>>>>>>>>> - Send an email to the webmaster of sites surfaced in the CT >>>>>>>>>> analysis which already have the styles that trigger the warning >>>>>>>>>> above. >>>>>>>>>> >>>>>>>>>> In addition to the above, the feature can be turned off with a >>>>>>>>>> server-side config using finch if there is any severe breakage. >>>>>>>>>> >>>>>>>>>> Please let me know if the above suffices. >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> Khushal >>>>>>>>>> >>>>>>>>>> On Wed, Jul 13, 2022 at 4:11 PM Khushal Sagar < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Jul 13, 2022 at 3:44 PM Mike Taylor < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 7/13/22 3:04 PM, Khushal Sagar wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Jul 13, 2022 at 6:12 AM Yoav Weiss < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wednesday, July 13, 2022 at 3:54:28 AM UTC+2 Khushal Sagar >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Jul 11, 2022 at 11:40 AM Yoav Weiss < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Fri, Jul 8, 2022 at 7:22 PM Khushal Sagar < >>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Contact emails [email protected], >>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Explainer >>>>>>>>>>>>>>>> https://github.com/WICG/shared-element-transitions/blob/main/overflow-on-replaced-elements.md >>>>>>>>>>>>>>>> https://github.com/w3c/csswg-drafts/issues/7058 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Specification >>>>>>>>>>>>>>>> https://drafts.csswg.org/css-overflow/#overflow-properties >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Summary >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This change allows developers to use the existing >>>>>>>>>>>>>>>> `overflow` property with replaced elements that paint outside >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> content-box. Paired with `object-view-box` this can be used to >>>>>>>>>>>>>>>> create an >>>>>>>>>>>>>>>> image with a custom glow or shadow applied, with proper >>>>>>>>>>>>>>>> ink-overflow >>>>>>>>>>>>>>>> behavior like a CSS shadow would have. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Blink component Blink>CSS >>>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> TAG review >>>>>>>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/750 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> TAG review status Pending >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Risks >>>>>>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This feature changes the behaviour of the existing overflow >>>>>>>>>>>>>>>> property on replaced elements (img, video, canvas). Currently >>>>>>>>>>>>>>>> `overflow:visible` in a developer stylesheet on such elements >>>>>>>>>>>>>>>> is ignored >>>>>>>>>>>>>>>> during paint and the content is clipped to the element's >>>>>>>>>>>>>>>> content-box. With >>>>>>>>>>>>>>>> this feature, `overflow:visible` will result in content >>>>>>>>>>>>>>>> outside the >>>>>>>>>>>>>>>> element's content-box to paint as ink overflow. We've >>>>>>>>>>>>>>>> collected use counter >>>>>>>>>>>>>>>> data to measure the number of sites which could be affected by >>>>>>>>>>>>>>>> this. The >>>>>>>>>>>>>>>> use counter data collected over 1 week of a stable release >>>>>>>>>>>>>>>> (M102) is as >>>>>>>>>>>>>>>> follows. We collected 2 different counters explained below. * >>>>>>>>>>>>>>>> The first >>>>>>>>>>>>>>>> measures any instance where overflow is explicitly set from >>>>>>>>>>>>>>>> developer >>>>>>>>>>>>>>>> styles to visible. The percentage of page loads with this is >>>>>>>>>>>>>>>> 2.16%. * The >>>>>>>>>>>>>>>> second measures the above instances but only includes the >>>>>>>>>>>>>>>> cases with >>>>>>>>>>>>>>>> object-fit set to cover or none or object-position set to any >>>>>>>>>>>>>>>> value other >>>>>>>>>>>>>>>> than the default (50% 50%). The rationale behind this counter >>>>>>>>>>>>>>>> is to exclude >>>>>>>>>>>>>>>> cases which can not cause overflow (such as >>>>>>>>>>>>>>>> object-fit:contain), even if >>>>>>>>>>>>>>>> overflow is set to visible. The percentage of page loads with >>>>>>>>>>>>>>>> this is >>>>>>>>>>>>>>>> 0.017%. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That's not nothing. Any idea what breakage may look like? >>>>>>>>>>>>>>> Can we maybe collect histograms on *how much* overflow would >>>>>>>>>>>>>>> occur in those cases? (maybe with ClusterTelemetry initially, >>>>>>>>>>>>>>> to get a >>>>>>>>>>>>>>> rough idea in the lab) >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I ran an analysis on CT using top 100k sites for desktop and >>>>>>>>>>>>>> top 10k sites on mobile. The raw numbers are here: desktop >>>>>>>>>>>>>> <https://docs.google.com/spreadsheets/d/1kKWq8kqZOfCXqiHaiamYNDdTs5x1_YJfDTnAgXOIwaE/edit#gid=0> >>>>>>>>>>>>>> and mobile >>>>>>>>>>>>>> <https://docs.google.com/spreadsheets/d/1SrNyrEe4yzCOIxqNOlNgCk8O58NqqoBlBTd4Wn_gKCc/edit#gid=0>, >>>>>>>>>>>>>> and the rough patch >>>>>>>>>>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/3749485> >>>>>>>>>>>>>> to >>>>>>>>>>>>>> collect this data. The highlights from the analysis are below: >>>>>>>>>>>>>> >>>>>>>>>>>>>> - The number of sites which override the default CSS to >>>>>>>>>>>>>> allow overflow *and* also had overflow during painting was 13 >>>>>>>>>>>>>> out of 10k on >>>>>>>>>>>>>> mobile and 39 out of 63k on desktop (only 63k sites yielded >>>>>>>>>>>>>> results out of >>>>>>>>>>>>>> 100k). >>>>>>>>>>>>>> >>>>>>>>>>>>>> - I measured the percentage of area painted outside the >>>>>>>>>>>>>> content box out of the total painted area. The highest was >>>>>>>>>>>>>> 88% on desktop >>>>>>>>>>>>>> and 70% on mobile. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> I'm not sure what that means in practice. Can you elaborate? >>>>>>>>>>>>> Have you looked at extreme cases to see the impact there? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Sorry, I should've added more details. :) I was looking for >>>>>>>>>>>> breakages with 2 numbers: sites with the largest number of >>>>>>>>>>>> overflowing >>>>>>>>>>>> pixels (such that other content could be occluded); sites with the >>>>>>>>>>>> largest >>>>>>>>>>>> percentage of image content outside the content box. But I realize >>>>>>>>>>>> the >>>>>>>>>>>> former is probably better to identify breakages. >>>>>>>>>>>> >>>>>>>>>>>> Looking at the top 10 sites, the worst affected is liveops.com. >>>>>>>>>>>> This has cases which use object-fit:cover so the image scales to a >>>>>>>>>>>> size >>>>>>>>>>>> bigger than its content rect and developer CSS overrides overflow >>>>>>>>>>>> to >>>>>>>>>>>> visible. Unfortunately, interacting more with this site, I did see >>>>>>>>>>>> images >>>>>>>>>>>> which are drawing above other content (screenshot attached) as you >>>>>>>>>>>> scroll >>>>>>>>>>>> down. This pattern showed up on the rest of the sites with high >>>>>>>>>>>> overflow >>>>>>>>>>>> numbers too (another example with screenshot attached). >>>>>>>>>>>> >>>>>>>>>>>> This kind of breakage is expected with this change. I'm not >>>>>>>>>>>> sure where to put the cutoff to identify sites with significant >>>>>>>>>>>> breakage, >>>>>>>>>>>> but there are at least 30 sites (out of 63k) that have images with >>>>>>>>>>>> more >>>>>>>>>>>> than 100px of overflow. The fix for the developer is to trace down >>>>>>>>>>>> the >>>>>>>>>>>> source of the overflow override and remove it. >>>>>>>>>>>> >>>>>>>>>>>> I'm not sure what's the recommended way to progress with a >>>>>>>>>>>> behaviour change like this given these numbers, the instances of >>>>>>>>>>>> affected >>>>>>>>>>>> sites seems low. Since the fix is simple, but hard to diagnose, >>>>>>>>>>>> one option >>>>>>>>>>>> could be to add a warning to the console: "overflow:visible now >>>>>>>>>>>> causes >>>>>>>>>>>> images to draw outside their bounds. Please make sure this style is >>>>>>>>>>>> intentional" for a few releases (credits to @Vladimir Levin >>>>>>>>>>>> <[email protected]> for the idea). Would that suffice? >>>>>>>>>>>> >>>>>>>>>>>> This feels like a fairly challenging bug to diagnose out >>>>>>>>>>>> without a DevTools issue >>>>>>>>>>>> <https://developer.chrome.com/docs/devtools/issues/> (or >>>>>>>>>>>> similar console message that links to some useful docs, as you >>>>>>>>>>>> proposed). >>>>>>>>>>>> Would we have the ability to conditionally create these for some >>>>>>>>>>>> overflow >>>>>>>>>>>> threshold value? >>>>>>>>>>>> >>>>>>>>>>> Sure, we can do this conditionally based on the area of >>>>>>>>>>> overflow. I'd be inclined to always do it if the UA style is >>>>>>>>>>> overridden to >>>>>>>>>>> allow overflow for at least a few releases. Since it's likely that >>>>>>>>>>> existing >>>>>>>>>>> sites are not overriding this style intentionally (because >>>>>>>>>>> currently it's a >>>>>>>>>>> no-op). Just to catch cases which don't show up in local testing >>>>>>>>>>> because >>>>>>>>>>> scaling of the image (with properties like object-fit) can depend >>>>>>>>>>> on the >>>>>>>>>>> form factor of the device. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> I manually went through ~10 sites on both desktop and mobile. >>>>>>>>>>>>>> For the ones which repro-ed, the breakage was losing rounded >>>>>>>>>>>>>> corners >>>>>>>>>>>>>> because border-radius doesn't clip the content if 'overflow' is >>>>>>>>>>>>>> 'visible'. >>>>>>>>>>>>>> In fact a few sites had the same code, likely coming from >>>>>>>>>>>>>> customerly <https://www.customerly.io/> based on class names >>>>>>>>>>>>>> and the UX. There was one case where an image (used in the >>>>>>>>>>>>>> background) had >>>>>>>>>>>>>> object-fit:cover and overflowed outside the content box now. >>>>>>>>>>>>>> I've attached >>>>>>>>>>>>>> screenshots for both of these. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Overall I didn't see any case where the overflow occluded any >>>>>>>>>>>>>> other content on the page. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> That's reassuring! :) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Gecko*: No signal ( >>>>>>>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/659) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *WebKit*: No signal ( >>>>>>>>>>>>>>>> https://lists.webkit.org/pipermail/webkit-dev/2022-June/032317.html >>>>>>>>>>>>>>>> ) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Web developers*: No signals >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Other signals*: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> WebView application risks >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Does this intent deprecate or change behavior of existing >>>>>>>>>>>>>>>> APIs, such that it has potentially high risk for Android >>>>>>>>>>>>>>>> WebView-based >>>>>>>>>>>>>>>> applications? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Debuggability >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This is a CSS property which can be debugged in the >>>>>>>>>>>>>>>> devtools style panel similar to other CSS properties. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>>>>>>>>>> Yes >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>>>>>>> ? Yes >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Flag name CSSOverflowForReplacedElements >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Note: Because of the compat risk with this feature, this >>>>>>>>>>>>>>>> flag can be controlled via Finch. This will allow us to >>>>>>>>>>>>>>>> rollback with a >>>>>>>>>>>>>>>> server-side config change if needed.* >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Requires code in //chrome? False >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Tracking bug >>>>>>>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1321217 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Estimated milestones >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> M105 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Anticipated spec changes >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> N/A >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>>>>>> https://chromestatus.com/feature/5137515594383360 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Links to previous Intent discussions Intent to prototype: >>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUykJWEAqVzcUy15fpBNdA68508Mny_1z--FCBKXRTZOFQ%40mail.gmail.com >>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/camluwuykjweaqvzcuy15fpbnda68508mny_1z--fcbkxrtz...@mail.gmail.com> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>>>>>>>>> <https://chromestatus.com/>. >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> 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 on the web visit >>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUze8JV6twLfhPBwkXj_UBMGApU048OdY33hYQn_KDj2rA%40mail.gmail.com >>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUze8JV6twLfhPBwkXj_UBMGApU048OdY33hYQn_KDj2rA%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 on the web visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUz9cutp%2BinEc3%2B7sdv%2B2TPoBbEeFCZjZFExBHSOL1p47A%40mail.gmail.com >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUz9cutp%2BinEc3%2B7sdv%2B2TPoBbEeFCZjZFExBHSOL1p47A%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 on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUy5zyHePkt06pjbtAE_vu1VjbybK5VXURhuSETyR%2Bu54g%40mail.gmail.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUy5zyHePkt06pjbtAE_vu1VjbybK5VXURhuSETyR%2Bu54g%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 on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUzdatCQP2_iBTPDo2gScAM1PH6Zmtj87UJD4g1UfmbsxA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUzdatCQP2_iBTPDo2gScAM1PH6Zmtj87UJD4g1UfmbsxA%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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_gE5FA-Y-xsj-Pbtq605Ocrkuu%3DPJkkymggRQnCOV3mg%40mail.gmail.com.
