> > 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.helf...@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 < > christoph.po...@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/CACw0rJDdBLUtAg8nHdjJy2cH9uXbXsiR%3DtON7k70vm5qtODQiA%40mail.gmail.com.
