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 <chris...@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 <msten...@chromium.org> >>> wrote: >>> >>>> Chris Harrelson <chris...@chromium.org> writes: >>>> >>>> > On Sun, Apr 16, 2023 at 11:45 PM Morten Stenshorne < >>>> msten...@chromium.org> wrote: >>>> > >>>> > Chris Harrelson <chris...@chromium.org> writes: >>>> > >>>> > > On Fri, Apr 14, 2023 at 5:09 PM PhistucK <phist...@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 < >>>> chris...@chromium.org> wrote: >>>> > > >>>> > > Contact emails >>>> > > >>>> > > chris...@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+unsubscr...@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+unsubscr...@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+unsubscr...@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+unsubscr...@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+unsubscr...@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+unsubscr...@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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_iP3ruVE%3DnASg7N7v0gPMxDdJWsZgPT7VLLcZwBBgthg%40mail.gmail.com.
