390936 - (csszoom) Implement Internet Explorer zoom property for css

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, enhancement)

Description

[Martijn Wargers (dead)]

(I couldn't find an earlier bug about this, which surprises me)

IE allows the css zoom property for content authors to allow magnifying various elements of choice in a page.
Maybe Mozilla should try to implement something like this, too?

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Based on what I know about this so far, I'm pretty strongly against it.

What are the use cases?

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(And when part of a page is zoomed, is layout changed, or does content disappear?)

Comment 3

[Martijn Wargers (dead)]

(In reply to comment #2)
> (And when part of a page is zoomed, is layout changed, or does content
> disappear?)

The layout is changed.
I don't really know of any use cases (other than it seems like a cool thing to be able to do).

Comment 4

[Dão Gottwald [:dao]]

Here's a use case: http://surfmind.com/lab/ie.html

At <http://www.beltzner.ca/mike/archives/2007/08/04/do_you_like_the_pretty.html>, "Andyed" claims it would be the only feature that makes him develop IE only apps. I didn't find a way to contact him.

I remember having used zoom once, but I can't figure out at which site. (I use it a lot to trigger hasLayout, but there was a real use case, too ...)
I guess it was something like this, i.e. an image or button enlarging on hover: <http://design-noir.de/Bilder/Urlaub/04_Abifahrt/Antibes/> (two occurrences: 1, the thumbnails. 2, the small images that appear if you move the mouse to the top of the page). Obviously, those work without 'zoom', since the absolute dimensions are known in the stylesheet and images can be zoomed with width/height.

Comment 5

[Martijn Wargers (dead)]

Fwiw, I think that the stuff at http://surfmind.com/lab/ie.html could be done with svg:foreignObject, but it wouldn't be as easy as a css zoom property, off course.

Comment 6

[Dão Gottwald [:dao]]

(In reply to comment #5)
> Fwiw, I think that the stuff at http://surfmind.com/lab/ie.html could be done
> with svg:foreignObject, but it wouldn't be as easy as a css zoom property, off
> course.

That's correct. On the upside, SVG would be semantically more correct, since the scaling is an integral part of the content, not a styling detail.

(In reply to comment #4)
> I remember having used zoom once, but I can't figure out at which site. (I use
> it a lot to trigger hasLayout, but there was a real use case, too ...)

Found one: http://www.menschen-finsteren-zeiten.org/4
'zoom' is used there to scale embedded images with the content.

#sub .lang-disabled {
	width: 20% !important;
	font-size: .53em !important;
	overflow: hidden;
}
#sub .lang-disabled > img {
	max-width: 40%;
}

and for IE 6 resp. 7:

#sub .lang-disabled img {
	max-width: 100%;
	zoom: 20%;
}

Comment 7

[Jason Orendorff [:jorendorff]]

I think many font-size use cases are really zoom use cases.

I hit one such use case in real life yesterday.  I wanted to animate some text.  The effect I wanted was "simultaneously fade in and shrink from huge to the correct size".  It's a zoom use case.  I ended up doing it by continually adjusting the font-size.  This caused lines to be reflowed as the animation progressed, which looked really ridiculous.

I tried solving this by simultaneously animating the width.  That works, *mostly*.  Enough rounding happens in layout that a word sometimes gets bumped from one line to another. (Ultimately I decided to use single words; of course one's content isn't always this flexible!)

Martijn says the layout *is* changed when you zoom; but I think that's only because the (effective-for-layout) width of the thing being zoomed changes (if you zoom in, layout sees its width decrease).  But--without getting too far into things I don't understand--I think you can arrange for that *not* to happen.  Correct me if I'm wrong, of course...

Comment 8

[Martijn Wargers (dead)]

There is now the -moz-transform: scale way of doing zooming with css. It's not like IE does the css zoom, but it is quite similar.

Comment 10

[Akkana Peck]

I have a non-web use case: I have a set of presentation slides scaled for 1024x768 projectors. Then I get asked to give the talk at a school or club where the projector only handles 800x600. Full-page zoom from the firefox UI doesn't work, because it resets on every slide.

-moz-transform: scale() works nicely, but it's a shame to have to maintain a special rule for firefox when CSS zoom: works in webkit and IE.

Comment 11

[henryfhchan]

zoom and scale work differently:
with zoom, the area allocated decreases by the zoom value,
with scale, the area allocated does not change.

This causes differences if you have a absolute positioned object to the right inside a zoomed object:
with zoom, the object stays in the right corner
with scale, the object moves left according to its transform origin.

Comment 12

[Huashimoto Fucaeka]

That's a good point henry.

Besides, W3C says that's a standard property for the CSS transitions. I think Mozilla should allow that.

Comment 13

[Huashimoto Fucaeka]

That's a good point henry.

Besides, W3C says that's a standard property for the CSS transitions (http://www.w3.org/TR/css3-transitions/). I think Mozilla should allow that.

Comment 14

[John Nagle]

As a use case, I'm working on an ad-blocker add-on which offers various levels of ad blocking. One level just reduces the screen real estate allotted to some ads. I tried using "zoom", and then discovered that Firefox is the only major browser that doesn't implement it.  

transform: scale(n), as mentioned above, is different; it doesn't affect the amount of real estate consumed. 

As an animateable property for transitions, it could be quite useful for pop-up boxes and things which expand when moused over.

Comment 15

[A. Lepe]

Here is another use case: We developed an internal system in which many reports are displayed. Most of these reports are to be printed in either single or double-size pages. The system is capable of splitting the reports automatically in several pages and display the pages on the screen. I added zoom-in and zoom-out buttons (like in a PDF viewer application) to visualize the whole pages. It works as expected in Chrome and Opera. Unfortunately I can not use that feature in FF.

Comment 16

[Natti Baron]

Hi, I'd like to point out our use case.

We've developed a new website dev tool, it's called Syndu, and can be viewed in www.syndu.com.
It takes an entirely different approach to developing websites than what's out there right now.
It's an html5 product, and relies heavily on jquery, css, etc.

The paradigm we use for the website is a desktop. There's no scrolling below the fold, content is shown inside content windows which can be moved around and scaled according to user, and/or viewers desire.

When users with netbooks (10",11" screens) browse the site, the "website desktop" is too large. We detect the screen size with javascript and apply the css zoom attribute on the entire document.
It works perfectly in Chrome, Opera, Safari, and IE. Firefox doesn't support it.

We tried running a css scale transform, but there are still problems with it and the dynamic windows elements. Dragging and resizing fail to render properly (this is happening across all browsers, and we consider it a maturity issue of the css-transforms).

Thanks.

Comment 17

[Brielle Harrison]

I agree with Natti Baron as well. I wanted to use this feature for some work at Netflix as I am a senior UI engineer there. On netbooks, it would have been ideal to be able to scale the site when certain media queries kicked in or when the resolution was below a certain threshold. 

The big problems with using transform: scale() is that the overall size of the component being scaled isn't adjusted in the DOM. So if you have an element that is 320px by 240px and you scale it to 50%, the element looks to be 160px by 120px but the white space surrounding it isn't decreased and the DOM still reports the element to be 320px by 240px. 

In all other major browsers, using zoom, this works as expected. It would be nice to know that Mozilla wasn't the only browser out but it seems to be that way.

Comment 18

[Michał Gołębiowski-Owczarek [:mgol]]

This is extremely important to me. My company is currently working with a heavily modified Seadragon Ajax technology, together with expanding it with a lot of OCR-like functionality. We need this OCR content to correctly change position and zoom to fit its Seadragon counterpart. In all major browsers apart from Firefox this is a simple question of setting top, left and zoom parameters. Firefox requires workarounds to achieve the same effect.

Any chance it will get implemented within a few months?...

Comment 19

[ForeverScape]

Yeah this would be a great help, or at least getting CSS3 transform to work properly with child elements. So far it does not scale when flash is a child object, and buttons etc. when placed dynamically into the dom scale all funky, too. I've found no solution so far that works in FF. Got it in IE and Chrome. =(

Comment 20

[jordan]

My use case:

I built a site from scratch, and everything looks great... except everything looks just a little too BIG, from a design standpoint.  I'm not a sophisticated developer or designer, so going back and scaling everything down would be a ridiculous chore, because it would require me to trace back through hack-land.

The "zoom" property is a hack solution.  I put it in the wrapper in my CSS, and it works beautifully on chrome and IE!  Looks like hell on Firefox though.

Would be absolutely wonderful for us to have this implemented soon!

Comment 21

[Michał Gołębiowski-Owczarek [:mgol]]

I used to advocate for this but I've changed my mind. CSS3 transform: scale() is much better and supported in all modern browsers.

Comment 22

[Rory O’Kane]

(In reply to Michał Z. Gołębiowski from comment #21)
> I used to advocate for this but I've changed my mind. CSS3 transform:
> scale() is much better and supported in all modern browsers.

Perhaps for your use-case, scale() is all you need. But note that the zoom property works differently from scale(), so there are reasons for Firefox to implement a separate zoom property. Comments #11, #14, and #17 here explain the difference between zoom: and scale(). In short, scale() changes the element only visually, while zoom: also changes the element “physically” in the layout.

Comment 23

[jordan]

transform: scale() doesn't have the ability to "zoom" in or out of the entire web page.  I built a site that I'd like to always look just a bit smaller; zoom really helps me out for that; transform: scale() does not.

Comment 24

[ForeverScape]

So it works in IE6-9, Chrome, Safari, Opera and now I have to write another special case for FF? Does not seems right. I'm perfectly happy with how zooming works and the site is just broken in FF. Scale just broke everything there's like 100's dynamically placed divs in a tight area with tons of css-- scale breaks it all zoom works like a charm.

Comment 25

[rheaton2020]

Please add support for the zoom attribute. With Opera moving to WebKit within a few months, they will restore support for it in a few months, and Firefox will be the only major browser left.

As spoken above, the following is a scenario by which support for this attribute would be helpful:

A developer builds a web site on a computer. This computer may have a width of 600px, 1280px, 2560px... whatever width. The developer would like to optimize this for any screen width, so that the content can be displayed at a default setting that will scale exactly the same way.

As others have said here, using the scale attribute followed by the .style['MozTransformOrigin'] attribute, doesn't do the same thing the zoom property is designed for.

Comment 26

[rheaton2020]

One other thing:

Here is a 1-line JS sample by which I could implement this property:

document.body.style.zoom = screen.width/1280;

1280 could be replaced with whatever screen resolution the web site was originally built for. With this, all you'd have to worry about is how it looks for your current screen resolution, without having to worry about the others.

Comment 27

[Sarah Hunt]

Adding one more vote to this. PLEASE. Firefox is the only major browser that doesn't support this. transform(scale) doesn't recalculate the bounds of an object, while zoom allows objects to reflow.

See this fiddle http://jsfiddle.net/sarahwhatsup/YDwds/18/

If nothing else, it feels extremely broken to have something work consistently in Internet Explorer, Chrome, Safari and *not* Firefox.

Comment 28

[rheaton2020]

With Opera Next 15 out, I have tested the zoom property on there, and it now works again with their switch to the Blink engine. This makes Firefox the only major browser left.

The zoom property is in the CSS Device Adaptation spec, both in the current Editor's Draft and in the latest Working Draft from 2011. http://dev.w3.org/csswg/css-device-adapt/

Comment 29

[Michał Gołębiowski-Owczarek [:mgol]]

(In reply to rkh2005 from comment #28)
> The zoom property is in the CSS Device Adaptation spec, both in the current
> Editor's Draft and in the latest Working Draft from 2011.
> http://dev.w3.org/csswg/css-device-adapt/

The spec you linked to is about the viewport zoom switch, not CSS zoom. Completely unrelated.

Comment 30

[danya.postfactum]

Use case: WYSIWYG rich text editor zoom tool, similar to MS Word, LibreOffice etc.

Comment 31

[Martin Karachorov]

One more vote for this (Now i have to rework a whole website just because this is not supported).

Comment 32

[marcin.habuszewski]

I wanted to use this css to make the whole page bigger in certain situation (zoom property would have been ideal), but I can't because FireFox does not support it. There are no simple alternatives to this (at all). The only alternative I see to using zoom would be to write an overload for the css which makes everything bigger, but I can't do that either as the site that I'm developing uses a 3rd party theme that has all text sizes set in px. Making this overload style sheet would be ridiculously time consuming.

Comment 33

[Axel]

For what it's worth: +1

Same problem here. Can't dynamically zoom using CSS transitions with the FF spezific workaround.

Comment 34

[contact]

Only 19 votes so far, still one of the most usefull functtion for mobile Dev.
Please add it.

Comment 35

[Jordan Ryan]

I'm also really surprised that this isn't supported in Firefox. Huge showstopper for mobile responsive development, going to have to refactor quite a bit. Yes, transform is not an equivalent solution, either.

Comment 36

[marcin.habuszewski]

Having messed a bit around making mobile apps in html, I found the zoom property to be extremely useful for adjusting the size of the content depending on resolution etc. Additionally development of those apps can be partially done with help of desktop browsers, but unfortunately only chrome appears to support this css decently.

Comment 37

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Microsoft wrote a brief (and incomplete) spec describing how 'zoom' works:
http://cdn.rawgit.com/atanassov/css-zoom/master/Overview.html
and brought it up in order to propose that all browsers agree to remove it (because it has crazy behavior that doesn't make sense).

zoom:1 is used frequently because:
 (a) it triggers hasLayout in old IE
 (b) it prevents pinch zooming on Android

The way non-1 values of zoom work is not explained clearly in Microsoft's draft.  What really happens is that:
 (1) the 'zoom' values accumulate multiplicatively from ancestors to descendants
 (2) all computed CSS <length> values are multiplied by that (but not percentages)

It seems like new IE will switch to the WebKit/Blink behavior, which means no longer applying anything to <percentage> values (not sure what they did there in the past), and not accumulating to inside iframes anymore.

Comment 38

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

... in today's CSS working group meeting.

Comment 39

[Axel]

My opinion: My intention is to zoom for "highlighting" active elements in a grid (table?).

I'd expect absolutely/relatively positioned elements to zoom from the center and leave all other elements unchanged, covering their content (depending on z-index property).

Comment 40

[Cameron McCormack (:heycam)]

(In reply to Axel from comment #39)
> My opinion: My intention is to zoom for "highlighting" active elements in a
> grid (table?).
> 
> I'd expect absolutely/relatively positioned elements to zoom from the center
> and leave all other elements unchanged, covering their content (depending on
> z-index property).

|transform: scale(...)| should work for this use case.

Comment 41

[Axel]

Yes, you are right. But the problem with the transform property is that you cannot set different transition timing properties for each of the transform functions to create animations beyond simple ones.

Comment 42

[Rory O’Kane]

(In reply to Axel from comment #41)
> Yes, you are right. But the problem with the transform property is that you
> cannot set different transition timing properties for each of the transform
> functions to create animations beyond simple ones.

Wouldn't `zoom` have this same problem? It's not like `zoom` provides extra capability for animation compared to `transform: scale()`.

If CSS’s built-in animation timing functions aren't enough for you, that means you have to use JavaScript to animate them. That should work the same whatever property you use – you are just setting the `style` attribute of the element to a string, and changing a number within the string with each update.

Comment 43

[Axel]

The problem with transform in general is that you can only have a single timing parameter set for transform. You can't, for example, have an element zoom in and then flip it around. (I know that's a stupid example but it pinpoints the issue rather well.)

The approach of how to achieve the desired transformation doesn't change the core problem.

Comment 44

[Cameron McCormack (:heycam)]

Some members of the CSS Working Group want to introduce separate translate, scale and rotate properties which are independently animatable and combine in a particular order.  That would allow simultaneous zooming and flipping.  I don't think that translate/scale/rotate properties is the best solution here -- it doesn't seem general enough to me -- but it indicates that at least some people in the WG feel that allowing independent transforms to be specified and combined on an element is a use case worth solving.

Comment 45

[Karl Dubost💡 :karlcow]

Tokyo Metro depends on it. 
https://webcompat.com/issues/1118

Comment 46

[Karl Dubost💡 :karlcow]

CircleSunKus depends on it.
https://webcompat.com/issues/952

Comment 47

[Karl Dubost💡 :karlcow]

Discussion in the CSS WG in May 2015
https://lists.w3.org/Archives/Public/www-style/2015May/thread.html#msg282

The resolution was   RESOLVED: Kill CSS Zoom with fire
:/ Still necessary for Web Compat reasons.

Comment 48

[Karl Dubost💡 :karlcow]

Ah no.
 RESOLVED: Kill CSS Zoom with fire
  RESOLVED: Rescind previous resolution
  <fantasai> plinss, basically, we don't have a resolution to "kill"
             anything unless we have a resolution to remove it from
             future releases of a browser. And we don't have that,
             because smfr is not convinced.

in https://lists.w3.org/Archives/Public/www-style/2015May/0282.html

Comment 49

[Karl Dubost💡 :karlcow]

Added another usage 
https://webcompat.com/issues/1551

Discussion about zoom use cases
https://lists.w3.org/Archives/Public/www-style/2016Feb/thread.html#msg63

Comment 50

[Karl Dubost💡 :karlcow]

Another dependency on zoom.
https://webcompat.com/issues/2103

Comment 53

[Karl Dubost💡 :karlcow]

Another site failing in multiple ways because of CSS zoom.

Comment 54

[Karl Dubost💡 :karlcow]

Another Japanese Web site relying on CSS zoom.
https://webcompat.com/issues/3789

Comment 55

[Alice0775 White]

not implemented yet.

Comment 56

[Matteo Ferretti [:zer0] [:matteo]]

Is there any update on this one?

I'm mostly interesting in `zoom: reset`, since I cannot find any equivalent implemented by Firefox (glad to be wrong!).

In devtools we need to display hud elements (e.g. infobars when we inspect element) that are not affected by the page's zoom. Currently, we applying a transformation with a `scale(1 / zoom)`, but it's not the same, we have several little visual glitches on high values of zoom or lower.

I'm looking for a good alternative, so far I found only `zoom: reset`.

Comment 57

[jonjohnjohnson]

Just chiming in to say that I'm glad firefox has held out on implementing 'zoom' and hope they always hold out. This property seems to make zero sense, if you build your applications in scalable/responsive ways, correctly using em/rem/% like values and the transform property, you should never need or even want to use zoom.

Comment 58

[Brielle Harrison]

Disagree entirely Jonjohnjohnson. The fundamental way that transform works is different, especially in regards to reflowing elements. Firefox remains the *only* browser that doesn’t support it. I’m glad transform works for you but it doesn’t work nearly as well as zoom for quite a few UI/UX behaviors

Comment 59

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 60

[Alfred]

Yes, zoom is not the same as transform. Zoom is for example superuseful for retina images where you just specify zoom: 50%. Firefox is as said before the only browser not supporting this. Would be really greatful for zoom to be implemented!

Comment 61

[Mike Taylor [:miketaylr]]

It seems like this isn't going away -> [webcompat:p3]

Comment 62

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

This would also be tremendously useful for our DevTools highlighter... canvas based highlighters get zoomed with the page so we need to divide by the zoom value in multiple locations, complicating our code.

Comment 63

[adrianhelvik100]

2 use cases. Previewing scaled down versions of authored content and adjusting content to better fit the display size for big screen displays.

For the last of two use cases we just don't support Firefox as it's simply too bug prone doing it using scale.

This may not be standard, but it is a de facto standard

Comment 65

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating webcompat priority whiteboard tags to project flags.

Comment 66

[Emilio Cobos Álvarez (:emilio)]

Note that this is not even so trivial, since some pages like the one in https://webcompat.com/issues/31557 (which right now work on release) use something like zoom and -moz-transform in the same rule.

Comment 67

[Thomas Wisniewski [:twisniewski]]

Indeed, we might even have to detect if a site is using zoom, and disable moz-transform and other moz-specific hacks to some degree to achieve compat (assuming we cannot just remove moz-transform due to unrelated compat issues).

Comment 68

[Thomas Wisniewski [:twisniewski]]

For testing reference, the few web platform tests I see using CSS zoom all seem to pass in Firefox, so further tests would appear to be needed. Thankfully I do see a fair number Blink web tests, as well as Blink and WebKit LayoutTests.

Comment 69

[samwelmunga88]

A very good reason in my opinion is that it makes the implementation of some accessibility components a breeze.

As seen here (using Chrome or I.E 10+):
lviamerica.com

And discussed here:
https://css-tricks.com/forums/topic/emulating-browser-zoom-with-css-for-accessibility/

Comment 71

[Karl Dubost💡 :karlcow]

Attachment: GitHub Pull Request

Basic Test on Web Platform Tests for CSS Zoom

Comment 72

[Karl Dubost💡 :karlcow]

See the recent discussions about it

astearns: PROPOSED RESOLUTION: avoid specifying zoom as it stands, but we will if we have to, and a new proposal about a better zoom property would be a good use of time
https://github.com/w3c/csswg-drafts/issues/5623#issuecomment-712455201

And I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1142663

Comment 73

[Karl Dubost💡 :karlcow]

Note that as-is the resolution doesn't resolve our webcompat issue. It leaves us at the same place. Except if Blink team is willing to move forward with https://bugs.chromium.org/p/chromium/issues/detail?id=1142663

Comment 75

[monkeyboyted]

Hi,

I am only here to point out another user of 'document.body.style.zoom'. This website uses zoom to make text larger. Disregard the obvious bug within the work around of quoting '-moz-transform'. I will report that bug to the website.

1. Navigate to https://medicare.highmark.com/view-plans?planType=Medicare%20Advantage
2. Enter any zip code. I used 15106
3. Click on the Text Resize Icon

Within zoomMe within https://medicare.highmark.com/etc.clientlibs/sxeaem/clientlibs/clientlib-base.min.js,

function zoomMe(zoomFactor) {
if (typeof zoomFactor === 'string' && zoomFactor.includes('%')) {
zoomFactor.replace('%', '');
zoomFactor = zoomFactor / 100;
}
document.body.style.zoom = zoomFactor
if (navigator.userAgent.includes('Firefox/')) {
document.body.style[-moz-transform] = 'scale(' + zoomFactor + ')';
}
}

Should I report to webcompat?

Comment 76

[Mr. TA]

This needs to be implemented ASAP, both in Firefox and added to the standard. All other browsers support it. The use cases are numerous: accessibility, document editors, etc. One important distinction from the transform scale approach is how pixel sizes are calculated: zoom multiplies then rounds, whereas transform rounds then multiplies; this makes transform unusable in many scenarios.

Comment 77

[Karl Dubost💡 :karlcow]

Hi Monkey,

(In reply to monkeyboyted from comment #75)

if (navigator.userAgent.includes('Firefox/')) {
    document.body.style[-moz-transform] = 'scale(' + zoomFactor + ')';
}

}

The bug is an easy fix and it is a site mistake. You did a correct analysis.
They probably do not need to use at all zoom. and probably could just use transform, which is supported by all browsers. You should contact them and you can tell me if you have been successful.

Should I report to webcompat?

You could on https://webcompat.com/issues/new
but you already did the job of diagnosing and maybe contacting. :) Thanks for this!

Comment 78

[John Nagle]

"Bug 390936 (csszoom) Opened 15 years ago. Updated 3 minutes ago".

This is an achievement of some sort. I'll comment again at the 20 year mark.

Comment 79

[monkeyboyted]

(In reply to Karl Dubost💡 :karlcow from comment #77)

Hi Monkey,

(In reply to monkeyboyted from comment #75)

if (navigator.userAgent.includes('Firefox/')) {
    document.body.style[-moz-transform] = 'scale(' + zoomFactor + ')';
}

}

The bug is an easy fix and it is a site mistake. You did a correct analysis.
They probably do not need to use at all zoom. and probably could just use transform, which is supported by all browsers. You should contact them and you can tell me if you have been successful.

Should I report to webcompat?

You could on https://webcompat.com/issues/new
but you already did the job of diagnosing and maybe contacting. :) Thanks for this!

Highmark released a fix but they left the browser specific check. Yes, the organization uses transform property

function zoomMe(zoomFactor) {

if (typeof zoomFactor === 'string' && zoomFactor.includes('%')) {
    zoomFactor.replace('%', '');
    zoomFactor = zoomFactor / 100;
}

document.body.style.zoom = zoomFactor

if (navigator.userAgent.includes('Firefox/')) {
    document.body.style['transform'] = 'scale(' + zoomFactor + ')';
}

}

Comment 80

[wig_2006]

I hope to Firefox Implement Internet Explorer zoom property for css to 15 years ago.

This is an achievement of some sort. I'll comment again up to 16-30 year mark.

Credit to describe browser compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/zoom

Comment 81

[Mr. TA]

To all those who say "transform" should be used: it's not the same behavior and therefore doesn't work in many scenarios. For me, the difference was that "zoom" multiplies, then rounds various sizes (like borders), whereas "transform" rounds then multiplies, which makes it impossible to have a border width of 0.3px and zoomed in 10x to make it similar to border width of 3px, for example. OK leaving aside the standard, why not just copy the implementation as it's done in WebKit as a stopgap measure?

Comment 82

[Emilio Cobos Álvarez (:emilio)]

Because the WebKit implementation is bogus, and reverse-engineering it without a clear spec is not going to create anything sane out of it. Also, because implementing this property will cause pages that right now work in Firefox (via -moz-transform, etc) to stop working, zoom doubly, etc.

For many of the use cases that zoom has if not all, you can use calc() and e.g. custom properties even though it might be a bit more effort.

Comment 83

[f.hazard]

Hi,
I am joining the discussion because I just discovered that the css property zoom is not supported by Firefox.

I developed a game on BGA in which one you could click a zoom button to open you player board in a larger dialog.
The player board is made up of many elements with relative and complexe positioning, this is why I choose to use the zoom property.

Please, let me show it on Chrome
https://imgur.com/a/J72tLMm

Zoom property is compatible with responsiveness.
(even if here it clearly needs a little fix on my side)
https://imgur.com/a/JuqdQdX

So on Firefox, the dialog is not zooming at all
https://imgur.com/a/L2zfXOA

Using -moz-transform is not completing doing the job
https://imgur.com/a/SifehrT

I hope I could use a wrapper element to force width with same aspect ratio but I am pretty I will have trouble to get it responsive.
The use case is not the same and I think this should be a standard.

Comment 84

[[e-mail]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #82)

Because the WebKit implementation is bogus, and reverse-engineering it without a clear spec is not going to create anything sane out of it. Also, because implementing this property will cause pages that right now work in Firefox (via -moz-transform, etc) to stop working, zoom doubly, etc.

For many of the use cases that zoom has if not all, you can use calc() and e.g. custom properties even though it might be a bit more effort.

I understand that implementing the zoom property can break those sites that don't expect it to work in Firefox. But why not implement it as -moz-zoom? The new code will be able to use this, and compatibility with the old one will remain.

Comment 85

[johnaweiss]

Firefox should support zoom. I expect to see Firefox support a feature that every other browser supports -- regardless of standards track.

https://developer.mozilla.org/en-US/docs/Web/CSS/zoom#browser_compatibility

This has been a bone of contention for 15 years. Enough is enough. Developers want it. Purists are against it for abstract purist reasons.

mozilla.org states:

"The non-standard zoom CSS property can be used to control the magnification level of an element. transform: scale() should be used instead of this property, if possible. However, unlike CSS Transforms, zoom affects the layout size of the element."
https://developer.mozilla.org/en-US/docs/Web/CSS/zoom

I think it’s not appropriate for you to recommend transform:scale – it’s a different functionality, different behavior.

There are known issues with transform:scale, to do with position and flow, with no easy workarounds. Particularly, subsequent element don't get repositioned to accomodate the transformed element. As your zoom article states:

"...unlike CSS Transforms, zoom affects the layout size of the element."

These aren't bugs, they are by design: transform isn't supposed to keep elements in the flow. Zoom is. transform:scale simply doesn't provide the same functionality as zoom.

There are no simple workarounds to make transform:scale act like zoom. Positioning can be sort of fixed with transform:origin 00, but no easy fix for the flow issue. In 2022, developers shouldn't need workarounds anyway.

Comment 86

[jscher2000]

I see this come up most often in the context of users reporting the Zoom controls are missing when using Excel online in Firefox:

• https://www.reddit.com/r/firefox/comments/navj6c/shared_spreadsheet_missing_option_to_zoom_sheet/
• https://support.mozilla.org/questions/1379162

Comment 87

[Simon Pieters [:zcorpan]]

I've manually analyzed 10 pages for CSS zoom, see https://docs.google.com/spreadsheets/d/1i7ErFvsRg9nwOfHTfeP7csPozjGZd0XKB-GXk1uhs4E/edit?usp=sharing

• 1 page has a minor visual difference and would be fixed by supporting zoom.
• 1 page would break by supporting zoom, unless we also unship -moz-transform (or make only one of them apply when both are specified on the same element).
• No impact for the other 8

(Same finding as in comment #67)

I did not test mobile, only desktop Firefox and desktop Chrome.

What is the feasibility of making -moz-transform have no effect if zoom is also specified?

Comment 88

[jscher2000]

(In reply to Simon Pieters [:zcorpan] from comment #87)

What is the feasibility of making -moz-transform have no effect if zoom is also specified?

If the scale factor in zoom and -moz-transform: scale() is the same, it would make sense to assume that the author only expected one to apply. Since this bug is for compatibility, it makes sense to prefer zoom in that situation and apply only zoom.

scale() takes either one or two parameters, so if there are two parameters with different values, i.e., asymmetric scaling, then the author may have wanted a different behavior in Firefox and maybe zoom should be ignored in that case. ?

Comment 89

[Emilio Cobos Álvarez (:emilio)]

(In reply to Simon Pieters [:zcorpan] from comment #87)

What is the feasibility of making -moz-transform have no effect if zoom is also specified?

Depends on what you mean with "have no effect", but I think the short answer either way is "rather tricky and/or quirky".

Do you mean not parse it? Parse it and support it in the OM, but somehow not honor it? Both are tricky in different ways. Maybe something else?

For "not parse it", generally the question is "what would trigger it". Say we see zoom, then -moz-transform, do we then ignore all -moz-transforms? With what granularity (for the whole page? For the same declaration block, ...)? What if we see -moz-transform and then zoom? Fixing that up to ignore the -moz-transform at parse-time is not really possible.

For the "not applying it in some cases" (basically comment 88), some context: -moz-transform right now is just a parse-time alias of transform. If we do something like comment 88, then the "easy" way would be to ignore transform as well. But I doubt that'd fly because I think zoom: 1; transform: scale(1); could be something potentially appearing on the wild, plus it's another compat hack that we wouldn't be able to get rid of and it affects standard transform. But if we decide to ignore -moz-transform but not transform, then it's even trickier because we'd need to either:

• Store both separately (they would no longer become aliases). Questions of what happens if you set -moz-transform: <something> then transform: <something else> (which can trivially happen as a result of CSSOM or what not) arise.
• Make -moz-transform a shorthand of transform, that sets a magic bit that says "this transform list came from -moz-transform". This bit wouldn't be reflected in serialization or anything else, and we'd use that to "ignore" transforms. That makes div.style.transform = div.style.transform potentially change behavior which is kind of hilarious, but might be the "less bad" option.

Ignoring those transforms at runtime is still not trivial, because transforms have other side effects other than applying the scale and so on (e.g., it also creates a fixed-position containing block for descendants etc). So it'd be rather hacky internally.

I do wonder what amount of breakage other than zoom would we find if we just unshipped -moz-transform tho, perhaps trying to unship it on nightly for a while and see if we see any non-zoom-related breakage could be a path forward? Then we could eventually disable -moz-transform and implement zoom in one go.

Though that said, zoom is still a huge mess as implemented in other browsers. e.g., it affects some CSSOM APIs like getComputedStyle, but not others like getBoundingClientRect, IIRC, and it's not even clear how it would really interact with others, or if that can ever be fixed... So I'd still be opposed to ship zoom without a spec for it that defines what works and what doesn't.

Comment 90

[Simon Pieters [:zcorpan]]

Thanks. Yeah, I agree "not parse it" is not viable. To make some sort of sense, it'd need to no longer be an alias to transform but its own property that is sometimes ignored (if zoom or transform is also specified on the same element).

Unshipping -moz-transform completely would indeed be cleaner, but I haven't checked what the breakage would be. This could probably be queried from httparchive with the tables in httparchive.experimental_parsed_css, looking for rules that include -moz-transform but not transform or -webkit-transform, and manually checking a handful. Testing on Nightly could also work but we might not get any bugs reported for only Nightly.

(Keeping my needsinfo to do this analysis.)

Comment 91

[Yarl]

16 years and no progress?! Add a damn this fucking property. It is necessary so that the page can be printed normally in firefox!! Thanks

Comment 92

[h_jac]

The functionality/use-cases of transform and zoom are so fundamentally different that it feels rather problematic that transform: scale is the only 'official' solution. Regardless of the debate around this specific implementation, there needs to be a means of scaling content along with the layout size of the element.

The majority of the cases against implementing zoom are over 10 years old. Simply put, they are no longer relevant. The landscape of the web has changed dramatically since this was first brought forth - and with the proliferation of web apps continuing well into the foreseeable future, the need for this feature should be abundantly clear. There are a number of detailed arguments in favor of this change in earlier comments, so I won't waste anyone's time regurgitating those points.

I invite any so-called 'purists' to make a renewed case against zoom, taking into account modern usage. Barring some new revelation, however, it would seem that this issue should be settled by the overwhelming support of the greater developer community.

I've had to develop features that don't work on Firefox and thus direct users away from using Firefox all-together on several occasions. That's likely not an experience unique to me, and even less likely to stop occurring. It's high-time to put this to bed.

Comment 93

[gandalf]

Web developer here. After reading all of the contention and everything regarding the zoom property, I have chosen to require support for zoom because I absolutely need the ability to zoom a sub-element and have it correctly affect layout size. Thus the website will not operate correctly under Firefox, and in the meantime I will advertise that viewing in Firefox is simply broken. Firefox developers, it's been long enough. Please code in this feature. Thank you.

Comment 94

[campleiter]

I think the last 2-3 comments really point out that is now time to implement this. Vote for zoom.

Comment 95

[Karl Dubost💡 :karlcow]

For your information, I did a review of the previous issue listed in the SeeAlso.
https://github.com/WebKit/standards-positions/issues/170#issuecomment-1530867635

Comment 96

[Emilio Cobos Álvarez (:emilio)]

Assigning to myself reflect the current state of things where:

• There's acknowledgement from the CSS Working Group that zoom is useful.
• It's unclear if it's implementable by Firefox or not due to the compat constraints.
• If turns out to be not implementable for us the working group would probably standardize it under some different name that all browsers could implement (tbd).
• So the main work items are prototyping it, see if/how terrible it is compat wise, see if we can move with Blink towards something saner (specially wrt getBoundingClientRect() and other CSSOM APIs), and depending on the outcome go back to the working group.

See https://github.com/w3c/csswg-drafts/issues/5623 for details and recent (last month) CSSWG discussions.

Comment 97

[Simon Pieters [:zcorpan]]

(I accidentally cleared my ni? -- see https://bugzilla.mozilla.org/show_bug.cgi?id=390936#c90)

Comment 98

[Hunter Perrin]

I just want to give a little information on why I couldn't get transform to support the use case I needed. I'm working on an email service, and the UI needs to scale wide emails down to fit on small screens. This is the code I have to do this:

const { width, height } = htmlContainer.getBoundingClientRect();
const { width: containerWidth } =
  htmlContainer.parentElement.getBoundingClientRect();

const scale = containerWidth / width;
const rightMargin = width - width * scale;
const bottomMargin = height - height * scale;

if (scale < 1) {
  htmlContainerStyles = `transform-origin: 0 0; transform: scale(${scale}); margin-right: -${rightMargin}px; margin-bottom: -${bottomMargin}px;`;
  htmlContainerScaled = true;
} else {
  htmlContainerStyles = '';
}

I'm using a scale transform, and reducing the element width and height with matching negative margins that are calculated from the scale factor.

This works really well for email without images or email where the images are immediately loaded from cache, but when an image loads and changes the height of the htmlContainer element, bottomMargin is no longer accurate and I get extra white space in the bottom of the element. Since I can't listen for load events for images (they don't bubble), I don't really have any solution here. Unfortunately, this means I have to use zoom, and Firefox users won't benefit from this feature.

I hope it helps to share a use case that isn't covered by transform.

Comment 99

[Emilio Cobos Álvarez (:emilio)]

Might be missing something, but why can't you use a ResizeObserver observing htmlContainer for that? Seems like that would be the obvious way to watch for changes to its size in a more general way. I guess there's the tricky bit of having to un-scale before measuring again, which is a bit subtle, but it should pretty much just work, unless I'm missing something.

Comment 100

[Hunter Perrin]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #99)

Might be missing something, but why can't you use a ResizeObserver observing htmlContainer for that? Seems like that would be the obvious way to watch for changes to its size in a more general way. I guess there's the tricky bit of having to un-scale before measuring again, which is a bit subtle, but it should pretty much just work, unless I'm missing something.

Actually, it does work, but unscaling and rescaling causes the page to scroll higher. So, if you're at the bottom of the email and an image loads, you end up getting scrolled part way up the email. That's better than nothing though, so I'm going to wrap that in an if (navigator.userAgent.includes('Firefox')). Thanks. :)

(I know I could save the scrollTop and reset it after rescaling, but this is such an edge case, I think it's fine.)

Comment 101

[Emilio Cobos Álvarez (:emilio)]

(In reply to Hunter Perrin from comment #100)

Actually, it does work, but unscaling and rescaling causes the page to scroll higher. So, if you're at the bottom of the email and an image loads, you end up getting scrolled part way up the email. That's better than nothing though, so I'm going to wrap that in an if (navigator.userAgent.includes('Firefox')). Thanks. :)

Sweet, but probably wrap it on a !CSS.supports("zoom: 2") or something along those lines, please. Otherwise you're causing the kind of problem that I fear would prevent us from shipping zoom to begin with :)

Comment 102

[Emilio Cobos Álvarez (:emilio)]

(And actually I guess you need the ResizeObserver everywhere so that you deal with viewport / user zoom changes or what not, but that's probably more edge-case-y...)

Comment 103

[lkss2]

PLEASE DO NOT UNDER ANY CIRCUMSTANCES CLOSE THIS ISSUE.

Instead, please push for making "zoom" an official standard to Google (Chrome, Edge, Android) and Apple (Safari, iOS) and anyone responsible.

Zoom is the only mechanism that:

1. In Chrome/Edge can modify the "CSS reference pixel" size successfully (well, almost: apart from canvas, which doesn't scale the same way as other elements).
2. Can be set with JavaScript (the scaling feature of browsers can't be modified with JavaScript).
3. Can be set to an arbitrary percentage value (like 103%) (the scaling feature of browsers doesn't offer such flexibility, nor do the "device emulation" tools in F12).

My use case is that I want to set the browser size to physical size of iPhone (i.e. ~0.1 meters width) and maintain the iPhone's logical width of ~390 points in width). This can only be achieved by modifying the size of "CSS reference pixel".

What doesn't work:

1. There are no extensions that would do this successfully (I tried a few and all didn't behave correctly).
2. There are no tools in "device emulation".
3. transform: scale(x) doesn't work the same as zoom.

What works:

1. The native mechanism of browsers (but it doesn't offer arbitrary percentage, just 100%, 110%, 125% etc. and it has no per-element scaling like with "zoom").
2. Zoom (except for canvas, which doesn't scale correctly in Chrome/Edge).

Please do not touch the "zoom" feature described here https://developer.mozilla.org/en-US/docs/Web/CSS/zoom (because it sounds like it could be removed) and please un-deprecate it. Or please implement an alternative mechanism (e.g. add to CSS "css-pixel-ratio: 1.04" instead of "zoom: 104%", which would do the trick or at least implement "any custom scaling like 103%" for browsers Chrome/Edge/Firefox/Safari).

Comment 104

[Simon Pieters [:zcorpan]]

(In reply to Simon Pieters [:zcorpan] from comment #90)

Unshipping -moz-transform completely would indeed be cleaner, but I haven't checked what the breakage would be. This could probably be queried from httparchive with the tables in httparchive.experimental_parsed_css, looking for rules that include -moz-transform but not transform or -webkit-transform, and manually checking a handful. Testing on Nightly could also work but we might not get any bugs reported for only Nightly.

Here are such pages, but also checking that zoom is absent:

https://docs.google.com/spreadsheets/d/1sFB38_--yCEJQaeT58NtnFG_pkQl9dMAYRVJdJgHhMQ/edit?usp=sharing

I think the best next step for the compat analysis is to implement zoom and remove -moz-transform and then manually checking the top pages in the list, comparing before/after, to see if anything is obviously broken by removing -moz-transform.

Comment 105

[Simon Pieters [:zcorpan]]

(In reply to Simon Pieters [:zcorpan] from comment #104)

https://docs.google.com/spreadsheets/d/1sFB38_--yCEJQaeT58NtnFG_pkQl9dMAYRVJdJgHhMQ/edit?usp=sharing

I think the best next step for the compat analysis is to implement zoom and remove -moz-transform and then manually checking the top pages in the list, comparing before/after, to see if anything is obviously broken by removing -moz-transform.

I've now looked at the first 100 with zoom enabled and -moz-transform disabled. Nothing is obviously broken by not supporting -moz-transform for these pages, which is encouraging. There were 2 sites that have some issues with how zoom is implemented (rows 42 and 56).

• https://www.ufs.ac.za/ Uses both zoom and -moz-transform for .SpotText. The size is correct, but the positioning is a bit off in Firefox Nightly compared to stable Firefox/Chrome.
• https://www.superhry.cz/ Uses both zoom and -moz-transform for .iconsA. The icons are implemented with a sprite and then set background-position to get the correct icon shown. In Firefox Nightly zoom doesn't affect intrinsic sizes for CSS background images, which breaks this page.

Adding ni? for me to look at pages using zoom generally to try to find any other issues.

Comment 106

[Simon Pieters [:zcorpan]]

In the comment above, for https://www.ufs.ac.za/ the positioning is off because it overrides left and bottom in @-moz-document url-prefix() (hack to target Gecko). Not much we can do about it except file a webcompat bug.

Checking the "red" pages in https://github.com/WebKit/standards-positions/issues/170#issuecomment-1530867635 in Firefox Nightly with zoom enabled and -moz-transform disabled (comparing with stable Firefox with default prefs).

• https://www.seedr.cc/ looks ok
• https://bonk.io/ uses zoom without fallback (e.g. in "quick play mode selection" window), so now renders as intended. 🎉
• http://ask8ball.net/ header now looks as intended. 🎉
• https://salah.com/ uses zoom without fallback (text size), so now renders as intended. 🎉
• https://mori-m-foundation.or.jp/english/ius2/gpci2/ with an Android UA string via devtools uses zoom on the root element, so now renders as intended. 🎉
• https://game.granbluefantasy.jp/ mobile via devtools uses zoom on the root element, so now renders as intended. 🎉

Checking the first 20 pages in "Adoption of the feature on top sites" in https://chromestatus.com/metrics/feature/timeline/popularity/3578 (no comment for pages where there's no impact):

• https://2ez.bet/ uses zoom: 0.95 on body, so now renders as intended. 🎉
• https://apostasesportiva.vip/ uses zoom and -moz-transform on .flag_small but expects background image intrinsic size to be affected by zoom so is now broken 🔴

Conclusions:

• Supporting zoom and not supporting -moz-transform is clearly a net improvement in terms of web compat.
• No issues found from dropping -moz-transform support.
• zoom needs to affect background image size.
• Still unknown if zoom needs to affect font-size (when font-size is not specified) and natural dimensions of img (when width/height are not specified), but probably safer to match Chromium/WebKit.

Comment 108

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 390936 - Enable CSS Zoom by default. r=#layout!,#webcompat-reviewers!

See intent to ship thread:

https://groups.google.com/a/mozilla.org/g/dev-platform/c/2xo3_A8as4E

Comment 109

[Vadim Makeev]

What’s the target version for shipping: 125?

Comment 110

[Emilio Cobos Álvarez (:emilio)]

No, 126 most likely.

Comment 111

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3ecb4aee23f9
Enable CSS Zoom by default. r=layout-reviewers,webcompat-reviewers,twisniewski,dholbert

Comment 112

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/3ecb4aee23f9

Comment 113

[Donal Meehan [:dmeehan]]

:emilio could you consider nominating this for a release note? (Process info)

Comment 114

[Emilio Cobos Álvarez (:emilio)]

Release Note Request (optional, but appreciated)
[Why is this notable]: Long-standing web compatibility fix
[Affects Firefox for Android]: yes
[Suggested wording]: The CSS zoom property has been enabled by default, following lots of web compatibility work, and standardization work in the CSSWG.
[Links (documentation, blog post, etc)]: https://drafts.csswg.org/css-viewport/#zoom-property

Comment 115

[Donal Meehan [:dmeehan]]

Thanks, added to the Fx126 nightly release notes, please allow 30 minutes for the site to update.
Keeping the relnote-firefox flag as ? to keep it on the radar for inclusion in the final Fx126 release notes.

Comment 116

[Vadim Makeev]

I just noticed that <h1 style="zoom: 10">Ten</h1> doesn’t work while <p style="zoom: 10">Ten</p> works just fine in Beta 126.0b2 and Nightly 127.0a1. Both Chrome and Safari zoom text in both cases. It seems like a bug in the implementation.

Comment 117

[Emilio Cobos Álvarez (:emilio)]

(In reply to Vadim Makeev from comment #116)

I just noticed that <h1 style="zoom: 10">Ten</h1> doesn’t work while <p style="zoom: 10">Ten</p> works just fine in Beta 126.0b2 and Nightly 127.0a1. Both Chrome and Safari zoom text in both cases. It seems like a bug in the implementation.

This is tracked in bug 1892676 now, but the nice thing to do would've been to file a separate bug, a lot of people do not pay too much attention to closed bugs :)

Comment 118

[Dave Letorey]

Related issues and pull requests

• Content PR
• Data PR
• BCD PR
• Firefox Release note PR