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.
