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.
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> >> . >> > -- 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/fb620e78-4b61-4911-b4f2-1a96c72b5a4en%40chromium.org.
