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 <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 [email protected] >> <mailto:[email protected]> 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 <[email protected] <>> wrote: >>>> >>>> On Mon, Apr 24, 2023 at 9:50 AM Noam Helfman <[email protected] <>> >>>> 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 <[email protected] >>>> <>> 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 <[email protected] <>> >>>>>> 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 <[email protected] <>> >>>>>>>> wrote: >>>>>>>>> On Wed, Apr 19, 2023 at 6:53 PM Chris Harrelson <[email protected] >>>>>>>>> <>> 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 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 <[email protected] <>> >>>>>>>>>> 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 >>>>>>>>>>> <[email protected] <>> wrote: >>>>>> >>>>>>>>>>>> Chris Harrelson <[email protected] <>> writes: >>>>>>>>>>>> >>>>>>>>>>>> > On Sun, Apr 16, 2023 at 11:45 PM Morten Stenshorne >>>>>>>>>>>> > <[email protected] <>> wrote: >>>>>>>>>>>> > >>>>>>>>>>>> > Chris Harrelson <[email protected] <>> writes: >>>>>>>>>>>> > >>>>>>>>>>>> > > On Fri, Apr 14, 2023 at 5:09 PM PhistucK <[email protected] >>>>>>>>>>>> > <>> 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 >>>>>>>>>>>> > <http://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 >>>>>>>>>>>> > <[email protected] <>> wrote: >>>>>>>>>>>> > > >>>>>>>>>>>> > > Contact emails >>>>>>>>>>>> > > >>>>>>>>>>>> > > [email protected] <> >>>>>>>>>>>> > > >>>>>>>>>>>> > > 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 [email protected] <>. >>>>>> >>>>>>>>>>>> >>>>>>>>>>>> > > 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 [email protected] <>. >>>>>> >>>>>>>>>>>> >>>>>>>>>>>> > > 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 [email protected] <>. >>>>>> >>>>>>>>>>>> >>>>>>>>>>>> > 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 [email protected] <>. >>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 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 [email protected] <>. >>>>>> >>>>>>>>>>> >>>>>>>>>>> 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 [email protected] <>. >>>>>> >>>>>>>>> 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 [email protected] <>. >>>>>>> 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 [email protected] >> <mailto:[email protected]>. >> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0EBFBA30-D54D-4323-BB52-326C9BB941B1%40gmail.com.
