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.n...@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+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 > <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/CAL5BFfXos-eARfu4AvsOB51yTDNMutM4Q%2BDnWkE8gnagHxbfQA%40mail.gmail.com.
