1589766 - Experiment with implementing zoom as a transform + transform-origin shorthand.

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, enhancement, P3)

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1589766 - Experiment with implementing zoom as a transform + transform-origin shorthand. r=xidorn

This is a gross hack, of course, but has the advantage of not breaking sites
that use both zoom and -moz-transform / -moz-transform-origin.

There should be no behavior change when the pref is off, of course, and the
webcompat team wanted to experiment with this.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Thomas, fyi, this should allow you to start testing this. I realized that the most recent "zoom" compat issue would've been fixed by this.

Known differences:

• Doesn't preserve the Number / Percentage distinction in specified style. So <div style="zoom: 200%"> will report div.style.zoom = "2" rather than "200%". This is a bit annoying to fix but not too bad if we implement https://github.com/w3c/csswg-drafts/pull/4396.
• Doesn't appear in computed style. This should be trivial to fix too if you want.

Let me know if you want it landed somehow and I can write basic tests.

Comment 3

[Thomas Wisniewski [:twisniewski]]

I would love it if we could land this on nightlies behind the flag, so our webcompat team can use it to ease their testing when zoom might be involved! That way we could build on it as we discover issues while live-testing.

I'll do my best to do some testing before it lands, and check against our known list of zoom issues (and also any tests in other browser repos).

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Alright, I added some extremely basic tests, and sent it for review. I don't think we need more for such a hack for now. If we decide we want to pursue this I can extend the tests.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

A thing we may want to do is just parse zoom if not 1.

Per https://twitter.com/fvsch/status/1185291905803923457 it seems a common hack for IE compat.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

I decided to land the pref on-on-nightly to catch obvious bustage that this approach could cause.

Comment 7

[Thomas Wisniewski [:twisniewski]]

Potentially good news, I just tried a local build with this hack applied, and all but two of the webcompat issues listed on the parent bug (which were not already fixed/invalid at this stage) have their zoom bugs fixed! These two still need investigation:

https://webcompat.com/issues/26009
https://webcompat.com/issues/38470

For both, there is content that becomes too narrow, rather than being full-width. There is also a floating icon on the first which goes into the middle of the page on Firefox, not the lower-right, and in the second the centering of the page is a bit off.

What do you think, Emilio?

Comment 8

[Emilio Cobos Álvarez (:emilio)]

The second I cannot reproduce on rdm, but it seems for the first Blink / WebKit are somehow factoring zoom on the root element to compute the viewport size... We could special-case that somehow, too, though I have no idea how that is supposed to work.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/97514cd3237c
Experiment with implementing zoom as a transform + transform-origin shorthand. r=xidorn

Comment 10

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/97514cd3237c

Comment 11

[Ksenia Berezina [:ksenia] on leave until 09/15]

There is an issue which is regressed by this experiment https://github.com/webcompat/web-bugs/issues/44334
When applying an inline style to a react component, if zoom property exists, it just overwrites an existing transform with transform & transform-origin. So if there is any repositioning involved (e.g. translate(-50%, -50%)), it gets lost.

A reduced test case: https://codepen.io/ksy36/pen/GRRXmqG

The issue in this particular case can be fixed by having scaling specified in one place, either transform or zoom, so I'll contact the site to see if they can fix it.

Comment 12

[Emilio Cobos Álvarez (:emilio)]

(In reply to Ksenia Berezina [:ksenia] from comment #11)

There is an issue which is regressed by this experiment https://github.com/webcompat/web-bugs/issues/44334
When applying an inline style to a react component, if zoom property exists, it just overwrites an existing transform with transform & transform-origin. So if there is any repositioning involved (e.g. translate(-50%, -50%)), it gets lost.

So that case is interesting, and kind of expected I suspect... zoom is completely unneeded in that case, it literally does nothing.

I guess we could map zoom to the scale property instead, it'd be way less risk of colliding with transform. WDYT Tom?