On Mon, Sep 12, 2022 at 4:59 AM Andre Bandarra <andre...@google.com> wrote:
> CC @Cheney Tsai <cheneyt...@google.com>, @Una Kravets > <unakrav...@google.com>, @Kadir Topal <kadirto...@google.com> > > 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 <miketa...@chromium.org> wrote: > >> LGTM2 >> >> On 9/9/22 12:16 PM, Khushal Sagar wrote: >> >> >> >> On Fri, Sep 9, 2022 at 11:37 AM Yoav Weiss <yoavwe...@chromium.org> >> 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 <khushalsa...@chromium.org> >>> 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 <khushalsa...@chromium.org> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Mon, Aug 1, 2022 at 12:11 PM Yoav Weiss <yoavwe...@chromium.org> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Mon, Jul 25, 2022 at 7:44 PM Khushal Sagar < >>>>>> khushalsa...@chromium.org> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Jul 20, 2022 at 5:17 AM Yoav Weiss <yoavwe...@chromium.org> >>>>>>> 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 <andre...@google.com> - 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 < >>>>>>>>> khushalsa...@chromium.org> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Jul 13, 2022 at 3:44 PM Mike Taylor < >>>>>>>>>> miketa...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>>> On 7/13/22 3:04 PM, Khushal Sagar wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Jul 13, 2022 at 6:12 AM Yoav Weiss < >>>>>>>>>>> yoavwe...@chromium.org> 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 < >>>>>>>>>>>>> yoavwe...@chromium.org> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Jul 8, 2022 at 7:22 PM Khushal Sagar < >>>>>>>>>>>>>> khushalsa...@chromium.org> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Contact emails khushalsa...@chromium.org, >>>>>>>>>>>>>>> vmp...@chromium.org >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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 >>>>>>>>>>> <vmp...@chromium.org> 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 blink-dev+unsubscr...@chromium.org >>>>>>>>>>>>>>> . >>>>>>>>>>>>>>> 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 blink-dev+unsubscr...@chromium.org. >>>>>>>>>>> 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 blink-dev+unsubscr...@chromium.org. >>>>>>> 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUzdatCQP2_iBTPDo2gScAM1PH6Zmtj87UJD4g1UfmbsxA%40mail.gmail.com.
