Closed Bug 1589766 Opened 2 months ago Closed Last month

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

Categories

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

enhancement

Tracking

()

RESOLVED FIXED
mozilla72
Tracking Status
firefox72 --- fixed

People

(Reporter: emilio, Assigned: emilio)

References

(Blocks 1 open bug, Regressed 2 open bugs)

Details

Attachments

(1 file)

No description provided.

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.

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.

Assignee: emilio → nobody
Flags: needinfo?(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).

Flags: needinfo?(twisniewski) → needinfo?(emilio)
Attachment #9102637 - Attachment description: Bug 1589766 - Experiment with implementing zoom as a transform + transform-origin shorthand. → Bug 1589766 - [not for landing] Experiment with implementing zoom as a transform + transform-origin shorthand.
Attachment #9102637 - Attachment description: Bug 1589766 - [not for landing] Experiment with implementing zoom as a transform + transform-origin shorthand. → Bug 1589766 - Experiment with implementing zoom as a transform + transform-origin shorthand.

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.

Assignee: nobody → emilio
Flags: needinfo?(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.

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

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?

Flags: needinfo?(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.

Flags: needinfo?(emilio)
Type: defect → enhancement
Priority: -- → P3
Attachment #9102637 - Attachment description: Bug 1589766 - Experiment with implementing zoom as a transform + transform-origin shorthand. → Bug 1589766 - Experiment with implementing zoom as a transform + transform-origin shorthand. r=xidorn
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/97514cd3237c
Experiment with implementing zoom as a transform + transform-origin shorthand. r=xidorn
Status: NEW → RESOLVED
Closed: Last month
Resolution: --- → FIXED
Target Milestone: --- → mozilla72
Regressions: 1593317
Depends on: 1593324
Regressions: 1593009
Regressions: 1595463

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.

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

Regressions: 1599072
Regressions: 1599324
You need to log in before you can comment on or make changes to this bug.