Last Comment Bug 390936 - Implement Internet Explorer zoom property for css
: Implement Internet Explorer zoom property for css
Status: NEW
parity-IE
:
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: -- enhancement with 23 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://msdn2.microsoft.com/en-us/libr...
: 524367 1254064 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-04 09:16 PDT by Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( )
Modified: 2016-03-07 04:42 PST (History)
38 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2007-08-04 09:16:39 PDT
(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-7 (review requests must explain patch) 2007-08-04 09:20:53 PDT
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-7 (review requests must explain patch) 2007-08-04 09:21:31 PDT
(And when part of a page is zoomed, is layout changed, or does content disappear?)
Comment 3 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2007-08-04 09:32:03 PDT
(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] 2007-08-05 02:52:48 PDT
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 [:mwargers] (gone per 2016-05-31 :-( ) 2007-08-05 08:01:09 PDT
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] 2007-08-05 10:18:21 PDT
(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] 2007-08-15 08:53:21 PDT
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 [:mwargers] (gone per 2016-05-31 :-( ) 2008-10-25 05:24:34 PDT
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 9 Matthias Versen [:Matti] 2009-10-25 12:06:43 PDT
*** Bug 524367 has been marked as a duplicate of this bug. ***
Comment 10 Akkana Peck 2010-06-20 11:12:59 PDT
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 2011-03-20 04:23:17 PDT
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 2011-06-03 06:52:01 PDT
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 2011-06-03 06:52:59 PDT
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 2011-10-12 22:48:39 PDT
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 2011-10-27 00:51:42 PDT
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 2011-11-19 05:59:51 PST
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 nyteshade 2012-06-01 00:33:59 PDT
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 [:m_gol] 2012-07-02 06:39:51 PDT
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 2012-08-08 16:19:14 PDT
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 2012-10-03 08:17:25 PDT
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 [:m_gol] 2012-10-03 14:11:29 PDT
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 2012-10-04 00:02:14 PDT
(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 2012-10-04 07:24:35 PDT
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 2012-10-04 10:17:54 PDT
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 rkh2005 2013-03-25 11:18:16 PDT
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 rkh2005 2013-03-25 11:32:20 PDT
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 2013-04-02 07:33:49 PDT
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 rkh2005 2013-05-31 22:43:15 PDT
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 [:m_gol] 2013-08-16 18:55:09 PDT
(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 2014-03-30 02:41:05 PDT
Use case: WYSIWYG rich text editor zoom tool, similar to MS Word, LibreOffice etc.
Comment 31 Martin Karachorov 2014-08-27 02:13:59 PDT
One more vote for this (Now i have to rework a whole website just because this is not supported).
Comment 32 marcin.habuszewski 2014-10-01 07:10:22 PDT
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 2015-01-28 17:43:55 PST
For what it's worth: +1

Same problem here. Can't dynamically zoom using CSS transitions with the FF spezific workaround.
Comment 34 contact 2015-02-02 03:24:54 PST
Only 19 votes so far, still one of the most usefull functtion for mobile Dev.
Please add it.
Comment 35 Jordan Ryan 2015-02-02 18:35:14 PST
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 2015-02-09 07:37:47 PST
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-7 (review requests must explain patch) 2015-05-18 14:05:51 PDT
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-7 (review requests must explain patch) 2015-05-18 14:15:03 PDT
... in today's CSS working group meeting.
Comment 39 Axel 2015-05-19 01:34:01 PDT
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) 2015-05-19 01:35:40 PDT
(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 2015-05-19 01:48:01 PDT
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 2015-05-31 20:55:54 PDT
(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 2015-06-01 01:08:23 PDT
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) 2015-06-01 01:15:01 PDT
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 2016-02-07 22:50:09 PST
Tokyo Metro depends on it. 
https://webcompat.com/issues/1118
Comment 46 Karl Dubost :karlcow 2016-02-07 22:51:19 PST
CircleSunKus depends on it.
https://webcompat.com/issues/952
Comment 47 Karl Dubost :karlcow 2016-02-07 23:03:43 PST
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 2016-02-07 23:04:52 PST
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 2016-02-17 18:38:24 PST
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 2016-02-18 22:29:52 PST
Another dependency on zoom.
https://webcompat.com/issues/2103
Comment 51 :Gijs Kruitbosch 2016-03-07 04:42:43 PST
*** Bug 1254064 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.