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?
Thanks, Alex 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 <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/4c24d7fe-7e68-4b8f-b16c-814d68667ac2n%40chromium.org.
