Hi Robin, This intent-to-ship is currently on hold while I investigate further the use cases and compatibility risk.
On Thu, Jun 22, 2023 at 8:09 AM Robin Haegeman <ro...@3daimtrainer.com> wrote: > What's the latest on this topic? Is this still an ongoing discussion or is > it decided to become deprecated from Chrome 117 onwards? Our application > relies heavily on it so ideally we have at least a couple of months to > adapt to this (and have some warnings in the console first a couple of > releases before). Chrome 117 seems rather fast in my opinion to just drop > support for a working CSS property, even if the usage is low. > On Monday, 24 April 2023 at 23:09:35 UTC+2 Malte Nuhn wrote: > >> Not to our knowledge, but we’ll dig deep into this. >> >> However, I can confirm that simply using transform: scale is not one of >> them: I’ve just done this in our app, and immediately run into the same >> issues we’d seen the last time we tried: scroll performance is awful, >> there is scroll jumpiness (especially when zoomed in deeply, probably >> something rounding-related), and pixelation. It basically defeats the >> purpose of working zoomed in . >> >> There may be ways to work around this we can implement it, or other >> approaches altogether; right now we don’t know what those would be but as I >> indicated we’ll dig in and report back. (Likewise, if anyone has ideas we >> can try them pretty easily). >> >> >> >> On 24 Apr 2023, at 17:47, Yoav Weiss <yoav...@chromium.org> wrote: >> >> Are there alternative ways to achieve the same effect that don't suffer >> from blurriness or other UX issues? >> >> On Mon, Apr 24, 2023 at 6:25 PM Malte Nuhn <malte...@gmail.com> wrote: >> >>> Similarly, online web design and authoring tools (like Framer, or our >>> OSS project at Utopia) rely on the zoom property for working when "zoomed >>> in". In Firefox (w/ scale as fallback) the result is a degraded (eg blurry) >>> experience - sometimes severely so, especially when shadows, serif fonts, >>> and SVGs are involved. >>> >>> In tools like these, the standard pattern is to use transform: scale >>> when the user is zoomed out ( < 100%) in the UI, and zoom when the user is >>> zoomed in, for maximum fidelity. >>> >>> FWIW I only this week discovered that zoom property removal was (back) >>> on the agenda and imminent. I suspect authors of the other tools are >>> similarly unaware. >>> On Monday, April 24, 2023 at 3:24:39 PM UTC+1 noam.h...@gmail.com wrote: >>> >>>> Thanks for sharing Noam, that's good to know! So is Excel Online >>>>> unsupported or completely broken for Firefox users then? >>>> >>>> >>>> The feature is disabled for Firefox. Since it represents a very small >>>> fraction of our users it is less of a concern. >>>> >>>> On Mon, Apr 24, 2023 at 5:04 PM Rick Byers <rby...@chromium.org> wrote: >>>> >>>>> >>>>> On Mon, Apr 24, 2023 at 9:50 AM Noam Helfman <noam.h...@gmail.com> >>>>> wrote: >>>>> >>>>>> I would like to point out that Microsoft Excel Online utilizes zoom >>>>>> CSS property heavily to perform the Excel grid zoom operations. >>>>>> Removing it would completely break our zoom functionality in the >>>>>> product and impact 100s of millions of users. >>>>>> >>>>> >>>>> Thanks for sharing Noam, that's good to know! So is Excel Online >>>>> unsupported or completely broken for Firefox users then? >>>>> >>>>> On Mon, Apr 24, 2023 at 3:05 AM Christoph Nakazawa < >>>>> christo...@gmail.com> wrote: >>>>> >>>>>> In a previous response it was stated that the removal of this >>>>>> property leads to only a small amount of code being removed, which I >>>>>> assume >>>>>> also means that there is little impact on reducing complexity in the >>>>>> engine. Maybe I missed it but is there an in-depth explanation of the >>>>>> intention and impact behind this change? >>>>> >>>>> >>>>> From my perspective as an outside observer / approver, the strongest >>>>> argument I see for doing this is cross-browser interoperability. That >>>>> could >>>>> also be achieved by getting a specification and tests written and support >>>>> added to Firefox. I don't personally think we should accept the status quo >>>>> of Chrome supporting this unspecified API indefinitely as it doesn't meet >>>>> our standards >>>>> <https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/> >>>>> for "plausible interoperability" between engines. It looks like +Rossen on >>>>> the Edge team started an effort to specify the feature >>>>> <https://github.com/atanassov/css-zoom>, but it stalled 8 years ago. >>>>> If this feature is important to Microsoft Office, then one option could be >>>>> for the Edge team to complete that work. >>>>> >>>>> >>>>>> On Thursday, April 20, 2023 at 10:42:17 PM UTC+3 Chris Harrelson >>>>>> wrote: >>>>>> >>>>>>> On Thu, Apr 20, 2023 at 12:01 PM Alex Russell <sligh...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> I agree that this is probably too risky right now. Are you willing >>>>>>>> to modify the plan you posted to gate #4 on a UKM analysis and/or >>>>>>>> driving >>>>>>>> use below a negotiated threshold, Chris? >>>>>>> >>>>>>> >>>>>>> I can do the UKM analysis if that's needed. As for threshold, I >>>>>>> think a randomized analysis percentage multiplied by the current >>>>>>> UseCounter >>>>>>> is good enough if the result is below some "safe enough" threshold. The >>>>>>> review of 62 sites, plus the fact that Firefox does not support this >>>>>>> feature, already makes me much more positive on success among the sites >>>>>>> that are measured by use counters, and some randomized UKM analysis >>>>>>> could >>>>>>> do even more. >>>>>>> >>>>>>> On Thursday, April 20, 2023 at 11:15:32 AM UTC-7 Chris Harrelson >>>>>>>> wrote: >>>>>>>> >>>>>>> Comments below, but here is a concrete shipping plan proposal: >>>>>>>>> >>>>>>>>> 1. Blog post describing what is happening, why, and how to fix >>>>>>>>> your code. >>>>>>>>> 2. Start a deprecation for 3 milestones (M114-116), with a >>>>>>>>> devtools console warning. Notify enterprises and webview clients of >>>>>>>>> the >>>>>>>>> deprecation. >>>>>>>>> 3. In parallel with #2: turn it off now via finch for canary/dev, >>>>>>>>> then later beta, to see if we get bug reports. >>>>>>>>> 4. Assuming no bug reports that raise new concerns, ship the >>>>>>>>> change in M117. >>>>>>>>> >>>>>>>>> On Thu, Apr 20, 2023 at 9:01 AM Rick Byers <rby...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On Wed, Apr 19, 2023 at 6:53 PM Chris Harrelson < >>>>>>>>>> chri...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>>> Mike said: *"It would also be good to go through all duplicates >>>>>>>>>>> and "See Also" bugs linked at >>>>>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=390936 >>>>>>>>>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=390936> and see how >>>>>>>>>>> we fare >>>>>>>>>>> with a build that has zoom disabled."* >>>>>>>>>>> >>>>>>>>>>> Good idea. I checked all 37 of the sites referenced from that >>>>>>>>>>> issue. I found only 3 that were even somewhat broken, and only 2 >>>>>>>>>>> where >>>>>>>>>>> there was something substantial (an "8-ball" image that was too >>>>>>>>>>> big, and a >>>>>>>>>>> facebook login that was cut off at some viewport sizes). Most sites >>>>>>>>>>> didn't >>>>>>>>>>> have any zoom at all. >>>>>>>>>>> >>>>>>>>>>> I also updated the "use cases" section with more use cases found >>>>>>>>>>> by reviewing the sites. >>>>>>>>>>> >>>>>>>>>>> Yoav said:* "Is it possible to also expose the usecounter as >>>>>>>>>>> UKM, and see the usage distribution? Given the high usage >>>>>>>>>>> percentage, it >>>>>>>>>>> can be reassuring to see that a) No large sites get broken by this >>>>>>>>>>> b) Long >>>>>>>>>>> tail sampling from UKM matches what y'all saw in HA"* >>>>>>>>>>> >>>>>>>>>>> It's possible. Based on the data I've provided (including >>>>>>>>>>> response to Mike above), do you think it's needed? >>>>>>>>>>> >>>>>>>>>>> On Mon, Apr 17, 2023 at 2:39 PM Rick Byers <rby...@chromium.org> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> First, you'll have a flag so we can kill-switch it if we see >>>>>>>>>>>> any non-trivial breakage in practice, right? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Already in place. CSSZoom is a base::Feature in addition to a >>>>>>>>>>> RuntimeEnabledFeature. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> WebView seems particularly risky, perhaps we should separate >>>>>>>>>>>> that out and leave it enabled on WebView at least to start? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'm willing to do that as a first step. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> What about enterprise, likely to be higher risk / needing a >>>>>>>>>>>> mitigation strategy? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'll add an enterprise flag for it, and ask for this change to >>>>>>>>>>> be highlighted in enterprise release notes. WDYT, good enough? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Works for me. >>>>>>>>>> >>>>>>>>>> From the HA analysis, were you able to get any upper bound on the >>>>>>>>>>>> fraction of sites with significant (i.e. usability impacting) >>>>>>>>>>>> breakage? Eg. >>>>>>>>>>>> can we spot check 100 pages that hit the counter to see if any >>>>>>>>>>>> look really >>>>>>>>>>>> broken? Alternately the UKM analysis Yoav suggests could help. >>>>>>>>>>>> I've been >>>>>>>>>>>> planning on figuring out how to do a UKM usage distribution >>>>>>>>>>>> analysis - this >>>>>>>>>>>> might make a good candidate. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I spot checked 62 sites from HTTPArchive and from the Mozilla >>>>>>>>>>> bug. In my view, none were terribly broken, and almost all were >>>>>>>>>>> unaffected >>>>>>>>>>> or had trivial changes. According to foolip's methodology >>>>>>>>>>> <https://sample-size.net/confidence-interval-proportion/> with >>>>>>>>>>> N=62 and x=0, that means that we've reduced the risk from the use >>>>>>>>>>> counter >>>>>>>>>>> of 0.5% to 0.028%. >>>>>>>>>>> >>>>>>>>>>> To get to 0.001% I'd need a lot more N, technically speaking. >>>>>>>>>>> >>>>>>>>>>> However, in basically all of the cases zoom was applied either >>>>>>>>>>> to very few elements or to the body; in the latter the site still >>>>>>>>>>> renders >>>>>>>>>>> fine (because browser zoom uses the same technique), and for the >>>>>>>>>>> others >>>>>>>>>>> it's at best cosmetic in almost all cases. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> That's great to hear. Given the usage is pretty high and there's >>>>>>>>>> at least some uncertainty among developers with how to replace their >>>>>>>>>> use of >>>>>>>>>> zoom (Christoph's note), WDYT about doing a blog post warning about >>>>>>>>>> the >>>>>>>>>> removal of zoom and showing how to replace it with transforms? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Sure, I can do that. Note that some sites already put >>>>>>>>> -moz-transform and zoom in their style sheet, so there is evidence >>>>>>>>> that >>>>>>>>> transform works ok for some use cases. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Also, should we consider a deprecation period with deprecation >>>>>>>>>> warnings in the console and available to the reporting API? Or is >>>>>>>>>> that >>>>>>>>>> likely to be so noisy with most cases being false positives that it >>>>>>>>>> would >>>>>>>>>> be net harmful do you think? >>>>>>>>>> >>>>>>>>> >>>>>>>>> A deprecation period makes sense. (Note that Firefox already has >>>>>>>>> warnings in their devtools not to use this feature.) >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Mon, Apr 17, 2023 at 4:55 PM Morten Stenshorne < >>>>>>>>>>>> mste...@chromium.org> wrote: >>>>>>>>>>>> >>>>>>>>>>> Chris Harrelson <chri...@chromium.org> writes: >>>>>>>>>>>>> >>>>>>>>>>>>> > On Sun, Apr 16, 2023 at 11:45 PM Morten Stenshorne < >>>>>>>>>>>>> mste...@chromium.org> wrote: >>>>>>>>>>>>> > >>>>>>>>>>>>> > Chris Harrelson <chri...@chromium.org> writes: >>>>>>>>>>>>> > >>>>>>>>>>>>> > > On Fri, Apr 14, 2023 at 5:09 PM PhistucK < >>>>>>>>>>>>> phis...@gmail.com> wrote: >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Any alternatives? I thought there was a section in the >>>>>>>>>>>>> intent templates for that... >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > One alternative for the use case mentioned in my earlier >>>>>>>>>>>>> email is to >>>>>>>>>>>>> > > apply a CSS transform instead. This will magnify the >>>>>>>>>>>>> subtree visually >>>>>>>>>>>>> > > but not cause a zoom-style layout change. >>>>>>>>>>>>> > >>>>>>>>>>>>> > The fact that a CSS transform doesn't affect layout, >>>>>>>>>>>>> whereas 'zoom' >>>>>>>>>>>>> > does, means that we'll paginate (fragment) properly with >>>>>>>>>>>>> 'zoom', but not >>>>>>>>>>>>> > with transforms, since they are applied after fragmentation >>>>>>>>>>>>> [1], causing >>>>>>>>>>>>> > content to be sliced across fragmentainer boundaries, and >>>>>>>>>>>>> the actual >>>>>>>>>>>>> > page/column breaks (as far as layout is concerned) are >>>>>>>>>>>>> shifted away from >>>>>>>>>>>>> > the fragmentainer edges visually, and will appear in the >>>>>>>>>>>>> middle of a >>>>>>>>>>>>> > page/column, for instance. >>>>>>>>>>>>> > >>>>>>>>>>>>> > [1] https://www.w3.org/TR/css-break-3/#transforms (never >>>>>>>>>>>>> mind the >>>>>>>>>>>>> > example there; it's not too relevant for this discussion, >>>>>>>>>>>>> but I can >>>>>>>>>>>>> > provide one if you want) >>>>>>>>>>>>> > >>>>>>>>>>>>> > Agreed that this is a difference. If a developer wants the >>>>>>>>>>>>> result to >>>>>>>>>>>>> > flow through fragmentation, they'll have to use the second >>>>>>>>>>>>> alternative >>>>>>>>>>>>> > I suggested. >>>>>>>>>>>>> > >>>>>>>>>>>>> > But in terms of web compat, I don't think this situation is >>>>>>>>>>>>> anything >>>>>>>>>>>>> > to worry about (e.g. I didn't see any fragmentation when >>>>>>>>>>>>> reviewing 25 >>>>>>>>>>>>> > random sites linked to from chromestatus.com). >>>>>>>>>>>>> >>>>>>>>>>>>> But as soon as someone prints any of those sites, there'll be >>>>>>>>>>>>> fragmentation. >>>>>>>>>>>>> >>>>>>>>>>>>> That said, I couldn't find anything bad on those sites, >>>>>>>>>>>>> either. I was >>>>>>>>>>>>> thinking that if it's actually okay to replace zoom with a >>>>>>>>>>>>> scale >>>>>>>>>>>>> transform, we really need authors to make such elements >>>>>>>>>>>>> monolithic >>>>>>>>>>>>> (because any break point inserted inside a transformed element >>>>>>>>>>>>> will more >>>>>>>>>>>>> likely than not end up in the middle of some page, rather than >>>>>>>>>>>>> at an >>>>>>>>>>>>> actual page boundary). So I changed the engine locally to >>>>>>>>>>>>> treat zoom != >>>>>>>>>>>>> 1 as monolithic. But that didn't make any of sites that I >>>>>>>>>>>>> tried look any >>>>>>>>>>>>> worse. >>>>>>>>>>>>> >>>>>>>>>>>>> > > Another alternative is for the developer to multiply the >>>>>>>>>>>>> numbers in >>>>>>>>>>>>> > > their CSS properties via calc + variables. >>>>>>>>>>>>> > >>>>>>>>>>>>> > That alternative should always work, but more cumbersome >>>>>>>>>>>>> for the >>>>>>>>>>>>> > authors, I suppose? >>>>>>>>>>>>> > >>>>>>>>>>>>> > Yes, a bit more cumbersome, but interoperable across all >>>>>>>>>>>>> browser engines. >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > > On Sat, Apr 15, 2023 at 1:03 AM Chris Harrelson < >>>>>>>>>>>>> chri...@chromium.org> wrote: >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Contact emails >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > chri...@chromium.org >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Specification >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > https://developer.mozilla.org/en-US/docs/Web/CSS/zoom >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Summary >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Removes support for the non-standard "zoom" CSS >>>>>>>>>>>>> property. This CSS property causes computed lengths for an >>>>>>>>>>>>> element to be >>>>>>>>>>>>> multiplied by >>>>>>>>>>>>> > > the specified zoom factor. >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Blink component >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Blink>CSS >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > TAG review >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > None >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > TAG review status >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Not applicable >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Risks >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Interoperability and Compatibility >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > This feature is only available in Webkit and Blink-based >>>>>>>>>>>>> browsers, and has been present in Chrome since the beginning. >>>>>>>>>>>>> Usage is a >>>>>>>>>>>>> little above >>>>>>>>>>>>> > > 0.5% of page loads: >>>>>>>>>>>>> https://chromestatus.com/metrics/feature/timeline/popularity/3578 >>>>>>>>>>>>> However, research shows that sites in HTTPArchive >>>>>>>>>>>>> > > triggering the feature mostly don't even seem to use it, >>>>>>>>>>>>> and those that do appear to always use it in a way that works >>>>>>>>>>>>> fine without >>>>>>>>>>>>> zoom applied >>>>>>>>>>>>> > > - worst case, just a very minor change to the size of a >>>>>>>>>>>>> tiny number of UI elements, but the UX is basically the same. See: >>>>>>>>>>>>> > > >>>>>>>>>>>>> https://docs.google.com/document/d/1cmbXpjAcXAht2ufi7bNKy-rbVNveqaf0UzeYg_DIMNA/edit# >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Gecko: Shipped/Shipping (Firefox never supported the >>>>>>>>>>>>> feature.) >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > WebKit: No signal ( >>>>>>>>>>>>> https://github.com/WebKit/standards-positions/issues/170) >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Web developers: Some web developers like the feature, in >>>>>>>>>>>>> particular for the use case of zooming in content in a legible >>>>>>>>>>>>> way with >>>>>>>>>>>>> responsive >>>>>>>>>>>>> > > design. See comments regarding that in this issue; >>>>>>>>>>>>> https://github.com/w3c/csswg-drafts/issues/5623 >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Other signals: The CSSWG has decided to not specify this >>>>>>>>>>>>> feature: https://github.com/w3c/csswg-drafts/issues/5623 >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Ergonomics >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > See "other views" section. >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Activation >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > N/A >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Security >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > None >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > 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? >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Maybe. WebView-based apps might use this feature. >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Debuggability >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Sites should be able to see that zoom no longer applies >>>>>>>>>>>>> to elements in devtools, though there is no warning planned. >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > 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? >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > No >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Flag name >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > CSSZoom >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Requires code in //chrome? >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > False >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Sample links >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > https://output.jsbin.com/yimuwax >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Estimated milestones >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Shipping on desktop 114 >>>>>>>>>>>>> > > DevTrial on desktop 114 >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Shipping on Android 114 >>>>>>>>>>>>> > > DevTrial on Android 114 >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Shipping on WebView 114 >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Anticipated spec changes >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Open questions about a feature may be a source of future >>>>>>>>>>>>> web compat or interop issues. Please list open issues (e.g. links >>>>>>>>>>>>> to known >>>>>>>>>>>>> github >>>>>>>>>>>>> > > issues in the project for the feature specification) >>>>>>>>>>>>> whose resolution may introduce web compat/interop risk (e.g., >>>>>>>>>>>>> changing to >>>>>>>>>>>>> naming or >>>>>>>>>>>>> > > structure of the API in a non-backward-compatible way). >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > None >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Link to entry on the Chrome Platform Status >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > https://chromestatus.com/feature/6535859207143424 >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Links to previous Intent discussions >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > This intent message was generated by Chrome Platform >>>>>>>>>>>>> Status. >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > -- >>>>>>>>>>>>> > > 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 on the web visit >>>>>>>>>>>>> > > >>>>>>>>>>>>> > >>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_2izF%2BTzHvALsKSxD_uLds%2BPAD7fLtvpX4Cwe7sTwU7g%40mail.gmail.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+...@chromium.org. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> > > To view this discussion on the web visit >>>>>>>>>>>>> > > >>>>>>>>>>>>> > >>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2Br8k-q-bKWGFKxgNbSy97UKGf7VUSMnrnURBJHor-x_w%40mail.gmail.com >>>>>>>>>>>>> . >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > -- >>>>>>>>>>>>> > Morten Stenshorne, Software developer, >>>>>>>>>>>>> > Blink/Layout, Google, Oslo, Norway >>>>>>>>>>>>> > >>>>>>>>>>>>> > -- >>>>>>>>>>>>> > 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 on the web visit >>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/87pm83knwv.fsf%40bud.servebeer.com >>>>>>>>>>>>> . >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Morten Stenshorne, Software developer, >>>>>>>>>>>>> Blink/Layout, Google, Oslo, Norway >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> 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 on the web visit >>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/87leiqkz3o.fsf%40bud.servebeer.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+...@chromium.org. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-XO6eyfHLNFJGf2RNL%3D8-4i2%3DoNCjK6X5MfB9ZCOaUfw%40mail.gmail.com >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-XO6eyfHLNFJGf2RNL%3D8-4i2%3DoNCjK6X5MfB9ZCOaUfw%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 on the web visit >>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8khSiw2o7dZ5S6qUjQsmdJ6XUb49q_a5NH1Pn7%2BmyA%3Dw%40mail.gmail.com >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8khSiw2o7dZ5S6qUjQsmdJ6XUb49q_a5NH1Pn7%2BmyA%3Dw%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 on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4c24d7fe-7e68-4b8f-b16c-814d68667ac2n%40chromium.org >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4c24d7fe-7e68-4b8f-b16c-814d68667ac2n%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> >>>> >>>> -- >>>> Noam Helfman >>>> >>> >>> -- >>> 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 on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e87d72f5-6e0c-4ee9-9b7d-6d64d39f9ec9n%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e87d72f5-6e0c-4ee9-9b7d-6d64d39f9ec9n%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 on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0b28d3ef-f527-4293-a8e1-fe72bda3e963n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0b28d3ef-f527-4293-a8e1-fe72bda3e963n%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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8eDsOH%3DgBG9BWcjBha7Rcfbm61Meb4AtZCZKB1xHV6%3Dg%40mail.gmail.com.
