How does this removal interact with the browser zoom feature? Today this seems to affect the CSS zoom property:
getComputedStyle(document.documentElement).zoom How much of the code do you get to remove, vs how much is still needed to support browser zoom but will have reduced web exposure? On Thu, Apr 20, 2023 at 12:01 PM 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? > > 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? > > >> 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/CACuR13ezTKBPffsp4nNyW4fhE7rLcz4AzHWWRrJw20fS0P0PAg%40mail.gmail.com.
