Intent to remove: zoom CSS property

[Chris Harrelson]

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.

[PhistucK]

Any alternatives? I thought there was a section in the intent templates for that...

☆PhistucK

--
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.

[Chris Harrelson]

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. Another alternative is for the developer to multiply the numbers in their CSS properties via calc + variables.

 

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.

[Stephen Chenney]

I seem to recall tests making use of CSS zoom. Is that not a concern? How do we write tests for issues that only manifest at particular browser zoom levels, because transform behaves differently than zoom (aka device scale factor)?

Stephen.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_yfVCi3aWq7X%3DhW%2BTUrPpdOZ7-L2bBxhHfQ9f%3DuRGObA%40mail.gmail.com.

[PhistucK]

Not sure which e-mail you are referring to.

I tried transform: scale(100) and I was pleasantly surprised to see that it did not make anything pixelated (I did not try raster image formats, of course, that must be pixelated even with zoom). I was worried it was not a good replacement, but it is for most intents and purposes. Thank you.

☆PhistucK

[Mike Taylor]

On 4/14/23 8:03 PM, Chris Harrelson 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#

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 and see how we fare with a build that has zoom disabled.

[Yoav Weiss]

On Sat, Apr 15, 2023 at 6:29 PM Mike Taylor <mike...@chromium.org> wrote:

On 4/14/23 8:03 PM, Chris Harrelson 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#

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 and see how we fare with a build that has zoom disabled.

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

Gecko: Shipped/Shipping (Firefox never supported the feature.)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/170)

https://github.com/WebKit/standards-positions/issues/170#issuecomment-1509480131 makes an interesting point that things could break when users actively zoom-in the page.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/745a0332-2bdf-5d77-e05d-56722211ffc1%40chromium.org.

[Morten Stenshorne]

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)

> 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?

--
Morten Stenshorne, Software developer,
Blink/Layout, Google, Oslo, Norway

[Chris Harrelson]

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).

 

> 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.

 

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]

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.

[Rick Byers]

I'm supportive of aligning with the CSSWG and Firefox here. But this does seem at least a little risky to me, so I think we need to carefully consider the launch plan.

First, you'll have a flag so we can kill-switch it if we see any non-trivial breakage in practice, right?

WebView seems particularly risky, perhaps we should separate that out and leave it enabled on WebView at least to start?

What about enterprise, likely to be higher risk / needing a mitigation strategy?

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. 

Rick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/87leiqkz3o.fsf%40bud.servebeer.com.

[Christoph Nakazawa]

Hey everyone,

I currently depend on the `zoom` CSS property since using `scale` in conjunction with perspective transforms results in a significant color washout in Chrome. My primary goal is to achieve pixel-perfect precision, and I'd be more than willing to transition away from `zoom` if this issue were resolved or if there is a viable alternative. It would be quite concerning if zoom was removed from Blink without an equivalent solution for this usecase.

Here are some examples (please download originals and compare locally):

Original with `zoom: 3` and `transform: perspective(125px) rotateX(2deg)`:

https://photos.app.goo.gl/GTPqE7kEotMPS7E36

With `transform: scale(3) perspective(125px) rotateX(2deg)`:

https://photos.app.goo.gl/R4nruLLYKC9TEtyu5

For comparison, here is what it looks like with just `transform: scale(3)` and without the perspective transform which does not have this problem:

https://photos.app.goo.gl/uwnhGEYobD448r2u6

You'll best see the difference near outlines, like the outlines for trees, mountains and streets look washed out in the version using `scale`. Similarly, fonts are not upscaled correctly with scale and a perspective transform either, compare https://photos.app.goo.gl/PFzzBbaJFLY4Sb7T6 (zoom) with https://photos.app.goo.gl/L82MfqmwRwpvqRHp8 (scale).

In my example, the canvas and DOM elements all have `image-rendering: pixelated` applied to them.

Thanks for considering this usecase.

Christoph

[Chris Harrelson]

Hi Christoph,

Thanks for the feedback. I left a omment inline below.

On Tue, Apr 18, 2023 at 8:19 AM Christoph Nakazawa <christo...@gmail.com> wrote:

Hey everyone,

I currently depend on the `zoom` CSS property since using `scale` in conjunction with perspective transforms results in a significant color washout in Chrome. My primary goal is to achieve pixel-perfect precision, and I'd be more than willing to transition away from `zoom` if this issue were resolved or if there is a viable alternative. It would be quite concerning if zoom was removed from Blink without an equivalent solution for this usecase.

Here are some examples (please download originals and compare locally):

Original with `zoom: 3` and `transform: perspective(125px) rotateX(2deg)`:

https://photos.app.goo.gl/GTPqE7kEotMPS7E36

With `transform: scale(3) perspective(125px) rotateX(2deg)`:

https://photos.app.goo.gl/R4nruLLYKC9TEtyu5

For comparison, here is what it looks like with just `transform: scale(3)` and without the perspective transform which does not have this problem:

https://photos.app.goo.gl/uwnhGEYobD448r2u6

You'll best see the difference near outlines, like the outlines for trees, mountains and streets look washed out in the version using `scale`. Similarly, fonts are not upscaled correctly with scale and a perspective transform either, compare https://photos.app.goo.gl/PFzzBbaJFLY4Sb7T6 (zoom) with https://photos.app.goo.gl/L82MfqmwRwpvqRHp8 (scale).

In my example, the canvas and DOM elements all have `image-rendering: pixelated` applied to them.

In these cases, you should be able to just multiply all of the CSS lengths in your style sheet, including the size of the canvas, by 3. Does this approach work on your site?

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aff83eb4-4a28-469f-a06c-5dba3e5d7cfan%40chromium.org.

[Chris Harrelson]

Thanks for checking that! It gives me more confidence that content is not broken substantially by this removal.

I agree with you that transform is not a full drop-in replacement for zoom, but it does meet a number of the use cases (which is why some of the sites, like Ask8ball.net, fall back to -moz-transform on Firefox). Multiplying all CSS lengths in style sheets should be a "full" replacement, though of course more tedious.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/87leiqkz3o.fsf%40bud.servebeer.com.

[Chris Harrelson]

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 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?

 

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 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.

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.

[Rick Byers]

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 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 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?

[Jeremy Roman]

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?

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.

[Chris Harrelson]

On Thu, Apr 20, 2023 at 11:00 AM Jeremy Roman <jbr...@chromium.org> wrote:

How does this removal interact with the browser zoom feature? Today this seems to affect the CSS zoom property:

getComputedStyle(document.documentElement).zoom

Browser zoom is implemented using the same machinery as CSS zoom. Removing the css property will make the code above no longer reflect browser zoom, though you can also read back browser zoom via window.devicePixelRatio (incorporates zoom as well as physical pixel ratio, so technically the developer would not know zoom independently of device pixel ratio, but I don't think there is a use case for that).

Note that getComputedStyle(document.documentElement).zoom will start returning undefined after this feature ships (just like in Firefox).

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?

Almost no code will be deleted - just parsing the CSS property and other generated code for getComputedStyle, and a few lines of code that computes the multiplied value of zoom when multiple ancestors have one.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuR13ezTKBPffsp4nNyW4fhE7rLcz4AzHWWRrJw20fS0P0PAg%40mail.gmail.com.

[Chris Harrelson]

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 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 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.)

 

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.

[Alex Russell]

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

>  >  To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@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.

--
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+unsubscribe@chromium.org.

[Stephen Chenney]

Back to the testing question. There are hundreds of blink web tests that set zoom via CSS. Most of them are not testing the zoom CSS feature itself (though some are) so most of them would need to be updated to test browser zoom situations. It's tractable, particularly if we modify the existing testing internals methods to enable arbitrary zoom.

While we're at it, I propose adding testing functionality to WPT for testing at different device scale factors. As far as I can tell it does not yet exist.

Is that step 1a? Step 0?

Cheers,

Stephen.

>  >  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.

--
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.

--

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.

[Chris Harrelson]

On Thu, Apr 20, 2023 at 12:30 PM Stephen Chenney <sche...@chromium.org> wrote:

Back to the testing question. There are hundreds of blink web tests that set zoom via CSS. Most of them are not testing the zoom CSS feature itself (though some are) so most of them would need to be updated to test browser zoom situations. It's tractable, particularly if we modify the existing testing internals methods to enable arbitrary zoom.

While we're at it, I propose adding testing functionality to WPT for testing at different device scale factors. As far as I can tell it does not yet exist.

Is that step 1a? Step 0?

Sorry for forgetting to reply to your email. 

These can be fixed by replacing zoom on the root element with an Internals method that does the same thing without a CSS property. The ones that set non-root zooms I plan to delete.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzSEsYqegJ2LJFCMjK-mpFitS0mcYKHei8b%2BbBonasQ5yA%40mail.gmail.com.

[Chris Harrelson]

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.

>  >  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.

--
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.

--

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.

[Noam Helfman]

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.

[Rick Byers]

On Mon, Apr 24, 2023 at 9:50 AM Noam Helfman <noam.h...@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 <christo...@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 for "plausible interoperability" between engines. It looks like +Rossen on the Edge team started an effort to specify the feature, 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.

[Noam Helfman]

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.

--

Noam Helfman

[Christoph Nakazawa]

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?

[Malte Nuhn]

Similarly, online web design and authoring tools (like Framer, or our OSS project at Utopia) rely on the zoom property for working when "zoomed in". In Firefox (w/ scale as fallback) the result is a degraded (eg blurry) experience - sometimes severely so, especially when shadows, serif fonts, and SVGs are involved. 

In tools like these, the standard pattern is to use transform: scale when the user is zoomed out ( < 100%) in the UI, and zoom when the user is zoomed in, for maximum fidelity.

FWIW I only this week discovered that zoom property removal was (back) on the agenda and imminent. I suspect authors of the other tools are similarly unaware.

[Yoav Weiss]

Are there alternative ways to achieve the same effect that don't suffer from blurriness or other UX issues?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e87d72f5-6e0c-4ee9-9b7d-6d64d39f9ec9n%40chromium.org.

[Malte Nuhn]

Not to our knowledge, but we’ll dig deep into this. 

However, I can confirm that simply using transform: scale is not one of them: I’ve just done this in our app, and immediately run into the same issues we’d seen the last time we tried:  scroll performance is awful, there is scroll jumpiness (especially when zoomed in deeply, probably something rounding-related), and pixelation. It basically defeats the purpose of working zoomed in .

There may be ways to work around this we can implement it, or other approaches altogether; right now we don’t know what those would be but as I indicated we’ll dig in and report back. (Likewise, if anyone has ideas we can try them pretty easily).

[Robin Haegeman]

What's the latest on this topic? Is this still an ongoing discussion or is it decided to become deprecated from Chrome 117 onwards? Our application relies heavily on it so ideally we have at least a couple of months to adapt to this (and have some warnings in the console first a couple of releases before). Chrome 117 seems rather fast in my opinion to just drop support for a working CSS property, even if the usage is low.

[Chris Harrelson]

Hi Robin,

This intent-to-ship is currently on hold while I investigate further the use cases and compatibility risk.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0b28d3ef-f527-4293-a8e1-fe72bda3e963n%40chromium.org.

[Chris Harrelson]

Update: the CSSWG just resolved to specify zoom, so please consider this intent retracted.