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+unsubscr...@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.
