The Power Of ZOOM - Fixing CSS Issues In Internet Explorer
Posted September 18, 2008 at 9:02 AM
I think we've all experienced how frustrating it can be to do cross-browser testing with CSS-based web sites. Why is it that Internet Explorer (IE) never seems to play nicely with good, solid CSS markup?!? Anyway, I just thought I'd share one technique that I've found to be extremely helpful. When I have some CSS that just won't work in IE, I see if adding a ZOOM property of 1 (one) will help:
Launch code in new window » Download code as text file »
- div {
- zoom: 1 ;
- }
I have to say, 90% of the time, this fixes the display issues that I am having in IE... and, it does so without adversely affecting any of the other browsers (that I have tested). I guess you could call this an IE-hack since I believe the zoom property is only supported by Internet Explorer.
I am not exactly sure why this works, but it has something to do with what you are trying to accomplish and the concept of an element having a "layout". In IE, some elements have a "hasLayout" property that is true by default. This is required for many visual settings; for example, an alpha filter only works on an element that hasLayout. So, why does {Zoom:1} work? It gives the target elements the hasLayout property.
There's a bunch of other things you can do to fix rendering issues in IE, but I have found {zoom:1} to be the lowest hanging fruit. For a more in depth look at what it means for an element to hasLayout, click here.
Download Code Snippet ZIP File
Post Comment | Ask Ben | Other Searches | Print Page
Newer Post
OOPhoto: Further Exploration Of The Facade And Controller-Model Interaction
Older Post
Ask Ben: Iterating Over An Unknown Number Of Nested Lists
Reader Comments
Ben...
Personally, I rarely find the need to write hacks for IE. If you're coding to standards compliant xHTML, and are using the Strict doctype, then it's usually a matter of knowing how to write CSS code which won't require hacks.
At most I might have to write some tweaks to my CSS which adjust the differences between border interpretation between IE and the other browsers.
@Andy,
I think we're on the same page. That's why I only mentioned Zoom here and not a bunch of other things. The propert Doc Type and nice markup are the best defense against hacks. However, I have found that some things just don't play nice.
The most recent example I ran across was applying an alpha filter to a Div. Worked fine in FireFox, but was ignored in IE because the DIV didn't have a set height and width (it has variable sized content). Howeer, when I added zoom:1, IE honored the alpha filter. I am not sure that any changes in the CSS or Markup would have fixed this?
Here's a handy CSS rule to see if your layout problems are related to IE and not your CSS. This quickly sets these values, which seem to be at the root of most IE rendering issues, for all elements.
* {position: relative; zoom: 1;}
@Steve,
While I like where you're going with that, I tend to shy away from mass-settings. It makes me feel more comfortable to fix issues as they are found, but that's a personal choice.
@Ben,
Agreed. This is primarily a debugging setting only to see if the problem is an IE rendering issue.
@Steve,
I can dig that idea :)
Elements with layout are responsible for laying themselves out and their children.
The DOM is essentially a big tree:
html
...body
......div
.........p
If the <body> has layout it's responsible for laying itself out on the screen and then placing it's children and sizing them. If we gave the p layout, it would then be responsible for this, instead of letting the < body > element do it.
http://msdn.microsoft.com/en-us/library/bb250481(VS.85).aspx
Note that you should always put hacks like this in a separate file and include it with conditional comments that target specific versions. Otherwise you might break badly in future versions of IE.
Hi Ben,
I found this little hack for IE based Issues or say FF based issues too related to the CSS.
In this statement:
width:20px;#width:23px:_width:20px;
FF applies the first width; IE7 applies the second one and IE6 applies the third one. This method works on all the CSS attributes too.
It may be extra code, but when clients are mad of their page lookup in IE6 too[people still use IE6 !!!], this is a nice hack
@Sanjeev,
Thanks for the tip.
This just solved me a lot of trouble! Thanks, Ben!
@Lindsay,
Glad to help!
Thanks for the tip. IE is sooooo damn lame! The zoom trick fixed me right up and saved me a lot of time.
I don't believe this simple code solved my problem*... and i don't believe i've never heard of this property before (and its use as a hack).
It's a life saver.
Thanks, Ben.
Cheers from Brazil!
* Some div content kept vanishing after using jQuery's slideDown animation method. Now solved with this simple hack. Internet Explorer keeps surprising me... :(
@Iran,
Awesome dude! Glad to help.
Ben, your post is interesting however! when using jQuery animate changing the opacity it seems to add a Zoom:1 into the inline style of the element this damages the element showing a double text effect as though the transition is only going 99% of the way.
This seems to be effecting a number of elements which use the fade or any other opacity transition the bug only happens in IE6.0 i have managed to fix this by removing the Zoom:1 using the css() functionality in jQuery.
is that a valid solution? i've noticed putting a background colour fix's it too! which is the best i have no idea!
Thanks
Dan
@Daniel,
I think when it comes to weird bugs, whatever you can do to fix it is the "right" thing to do :)
Hi Ben
I have used your code in my stylesheet and seems to work fine in IE but it seems to not like in my CSS code it shows the following error
Validation CSS 2.1 Zoom is not a known CSS property name
Can this bit of code be used in a stylesheet?
thanks
@Angel,
Zoom is an IE-specific CSS property. As such, I don't think it will validate. However, it is ignored by browsers that don't use it.
Fabulous!! thanks Ben for taking efforts and sharing this solution. It worked well for me.
Thanks a ton,
Rashmi
@Rashmi,
Glad you're liking. I still use this all the time.
the problem is that: ZOOM is a non standard property so you will no pass the W3C CSS check... especcialy with a DTD STRICT...
and on IE 6 blokcs the magnification of the text so it gives problems for accessibility...
@Andrea,
I suppose for validation, you could always add a zoom class post-page-load with Javascript? As far as blocking the zoom functionality in IE6 - I'll be honest with you, I don't even know what zoom does. I've never seen anyone use it in real life.
If you use the conditional statements for IE it will validate just fine, if that concerns you. IE conditional statements are just comments as far as every other browser is concerned, which no validator should examine.
Browser support of CSS is so full of holes that I don't bother with trying to achieve 100% validation unless it's a showcase site where people are likely to check it out. That's just wasting my client's money in most cases. It's more important that a site works perfectly (if not exactly the same) in 99% of actual browsers in use than it is to pass validation in a system that isn't itself 100% well-defined. Using Strict doctypes is something I do as a matter of course, but it often isn't much more reliable than using none at all, and non-compliant browsers are everywhere. With all the phones and mobile devices in use the situation is getting worse, not better.
Figuring out the hasLayout behaviour of IE is worthwhile, even if it sometimes appears totally illogical. Unlike the earlier versions of Firefox and Safari, many people are actually still using IE6 and 7... I wish they weren't but it's just not going to go away any time soon. (Having said that, I spotted a user in my stats recently apparently still using Netscape!)
@Bro,
Still using Netscape!!! That's just bananas!
Validation is something I always try to aim for, but sometimes you can write the most standards compliant code in the world and you'll still get IE barfing. Had one today in IE7 where a background image applied to an inline element just disappeared when the element included a line break.
I hate hacks - and won't use anything like Tantek's hack or anything like that - however I'll cope with using things like zoom:1 or the odd "superfluous" position:relative if I have to - at least they can't possibly have any ill effects in other browsers. Even if someone else does implement zoom, then zoom:1 just means "don't zoom".
Apparently Zoom does just that - it zooms. If you put zoom:200% it will magnify your element to double the size. Bit like Firefox and Opera do when you zoom an entire page - but just for one element.
@Andrew,
I've never actually played around with anything that wasn't zoom:1 (meaning, I've never tried zoom:2). I'll have to give that try.
I think validation is nice, but not at the sacrifice of user experience; at the end of the day, a consistent, compelling user experience is the most important feature of any public-facing service. And, if a small hack makes that possible, I am all for it.
