how to make ie6 behave/core fixes
As of now, we released a tool that automates these ie6 fixes for your given css file. Check out our IE6 CSS Fixer tool.
As I explained in my previous article on ie6 debugging, it's all about fixing the core of the problem, not about tweaking values to make a design look right. I realize this might sounds a bit vague, so this post will look into some examples where core fixing could save you a lot of time and turn the battle with ie6 into your favor. Buckle up for some good ole ie6 weirdness.
The purpose of this article is to identify ie6 misbehavior and to find solutions that force ie6 to behave like other browsers do. None of these bugs or solutions were identified by myself, for that sites like quirksmode are invaluable.
fix min values
div {min-height:100px;}
/* ie6 fix .............................................. */
div {height:100px;}
Sometimes applying a min-height or min-width value to an element is a necessary evil. Sadly, ie6 doesn't know how to handle these css properties, so a workaround was needed. Ironically, another ie6 bug was exploited to fix this issue. It suffices to place the same value declared as simple height or width. The behavior of these css properties in ie6 is the same as the min-height and min-width properties in other browsers.
fix floats
div {float:left;}
/* ie6 fix .............................................. */
div {display:inline;}
Many ie6 bugs are connected to floats, luckily they can be fixed quite easily. Even though floats are supposed to act like block elements, adding a display:inline declaration will make floats behave in ie6 like they're supposed to. And regardless of the display value assigned, they will still act like block elements (ie. accept paddings, margins, widths etc).
fix position:relative
div {position:relative;}
/* ie6 fix .............................................. */
div {zoom:1;}
The position:relative declaration is probably the most dangerous of css declarations for raising ie6 issues. Depending on how many are nested, they can start acting up and completely mess up your design. And they are sure to mess up the position of your absolutely positioned elements. All of that can be fixed by adding a zoom:1 to each element bearing a position:relative. If you don't know what zoom:1 does or where it comes from, read up on the hasLayout issue here.
The only reservation here is that zoom:1 is best not used on inline elements, as they will start behaving like block elements. It's rare to put a pos:rel on an inline element, but it's better to be alert when applying ie6 fixes.
fix negative margins
div {margin:-0.5em;}
/* ie6 fix .............................................. */
div {position:relative; zoom:1;}
Negative margins are another thing ie6 doesn't like to handle. To make them work as intended, you need to apply a position:relative declaration to the element bearing the negative margin. Keeping the fix above in mind, you'll also need a zoom:1 to make the pos:rel behave. A solid fix, but with the same reservation as above, keep these declarations away from inline elements just to be sure.
fix overflow hidden
div {overflow:hidden}
/* ie6 fix .............................................. */
div {zoom:1;}
And yet another zoom fix. I'm not really sure when ie6 starts messing up overflow:hidden declarations, but a zoom:1 is sure to fix all when it starts to go wrong. Again, keep your zoom:1 away from inline elements, though I wonder why you'd want to set an overflow:hidden declaration on an inline element.
is there more?
No doubt there is more. I'm not an expert on ie6 debugging, but for the greater part these are issues that pop up with every project, and getting these fixes in as quickly as possible makes for much easier ie6 debugging afterwards. Whether you create your ie6 css alongside your main css or run through your main css to construct a ie6 css when everything is finished is entirely up to you. But when you make sure all the above is taken care of, ie6 will look like a much nicer browser.
Hi Niels. What an excellent article - straightforward and to-the-point explanations of some of the most common IE6 issues. A couple of points, though:
The references to relative positioning are very interesting - totally new to me. I'm intrigued to know what the bugs are.
I think you need to be careful to make a distinction between 'safe' fixes, and those with side-effects. It may not be clear that certain solutions demand a CSS filter of some description to 'protect' the good browsers - the min-height/height fix is, I believe, the only 'unsafe' example here.
The second "where" on this page needs to be a "were" :)
1/ I'm not too sure about the behavior of pos:rel in ie6, but I've noticed several times that depending on how many nestings there are, certain elements can jump their place (usually an offset value to the top left of the element. Another problem is related to the use of pos:rel in combination with paddings and margins, making the offset values for absolutely positioned elements inside different for ie6. All of this can be fixed by adding that zoom:1 though. If I find the time I could make some example cases.
2/ You're right about that, but I assume that people are aware of what to do with these fixes. Apart from the min-height/width fix, the extra pos:rel could also be of influence to some nested absolutely positioned elements I guess.
And thanks for pointing out that little error!
One of the best round up I've seen about IE6 CSS fixes. The only thing that I don't like 'zoom:1' is that is not validated.
For me personally, css validation is not a big priority, though my main css file is usually clean enough (only errors I get are caused by opacity rules).
And those zooms are in a separate IE css anyway, so I usually don't worry too much about using them. Especially since they prove to be so useful :)
Quote:
"One of the best round up I've seen about IE6 CSS fixes. The only thing that I don't like 'zoom:1' is that is not validated. "
Use a conditional ie.css (only IE6 users will load extra stylesheet) and place in there.
For validating CSS markup, have you 'validate CSS' link point to your main master.css/layout.css etc, rather than including the hacks in your validating CSS file.
personally, i think css validation should be a priority for everyone who writes css. there are rules out there that were written for a reason, and we should adhere to them wether a client/boss tells us to or not.
while i do realise the point of this post - quick fixes to ie6 quirks - i think more should be made on ie6 hasLayout 'feature', and ways that we can fix these without using hacks. more than half of the quirks you name are directly related to the hasLayout 'feature', and can be fixed (given the offending element a dimension for -- one very quick -- example).
as for the other two (the first two), you should point out that min-height issue can be fixed by creative markup rather than using a hack. i'd always rather add an extra div than using a hack. and the float fix fix can be used cross browser -- you don't need to separate the display:inline rule from your other browser rules.
i honestly believe - and this comes with 9 years experience as a web dev - 99.9% of browser 'bugs' can be fixed in the markup. providing you're using valid markup and semantic css selectors, there is nothing wrong with being creative if you need to be.
as for:
"For validating CSS markup, have you 'validate CSS' link point to your main master.css/layout.css etc, rather than including the hacks in your validating CSS file."
really, what's the point? that could be re-written as 'get around validation errors by hiding all your hacks from the validator'. why stop there? why not have a css file that you use for everyone of your sites called 'valid.css' that is an empty file and point your validation links at that?
@danny
Whilst validation is important, HTML+CSS are increasingly being stretched to breaking point resulting in difficult decisions of whether to validate or not.
Example: the W3C ARIA project, an excellent initiative aiming to improve accessibility on the web, can only be realised with invalid HTML. Or through the use of javascript, which may not be available, and therefore partially defeats the purpose.
I think it's far more important to understand the consequences of a specific element/attribute/declaration not validating, and exercising sensible judgement.
2 comments:
if microsoft wrote browsers that followed the rules, we wouldnt have to break the rules to fix them.
while this article is good and all that, shouldnt we really be saying F IE 6 at this point in time? if someone still uses this horrible, insecure, piece of crap browser they SHOULD have to suffer the "horrible" consequences of broken webpages. its time to stop worrying about the lowest common denominator.
i realize not everyone has this luxury though.
It's not even a point of luxury, some people actually like ie6 as a browser. Mostly because they want to surf the web and don't give a damn about xhtml, validation and browser bugs. I don't really blame them either, because many people failed to switch to newer browsers as they saw their favorite sites "break" in newer ones.
If anyone is at fault it's probably the web developers from a couple of years back, failing to write good code and just whip something up that worked in ie6. It's probably better to curse them.
Fact is, ie6 still has a pretty huge market share, so until it drops, we're stuck with it.
This may have been mentioned before but a good way to only target IE with your selectors is to use the following:
That way it won't unintentionally affect any modern browsers. Putting * html is a selector that exploits a bug in IE that essentially wraps every Web page in two html tags. This will only affect IE 6 and below.
very very useful roundup. I would like to see a follow up article
I like this list, some of this stuff I have never tried. But generally I don't have many problems with IE6 anymore. I make it look 95% good, and fix PNG issues, and that's about it.
But I am a little skeptical about the universal use of some of these css values. The title of this article implies that these fixes are essentially guaranteed, but that is never the case with IE6. There is no method to IE6's madness. The only solution to IE6 issues is to stop developing for it and force users to upgrade.
In fact, the joyous responses to this article concern me that web developers are still trying to fix IE6 issues, when instead they should simply leave it be and allow the web to move forward.
Great article!
Moving the web forward should never be a goal in itself. Making the web a better place for its users should. And if 20% of your users is still using ie6, you should be doing your best to accommodate them as well as possible.
Leaving ie6 out of the loop now is not beneficial to all its users, even those who'd want to upgrade if they had the chance.
min-height followed by height will allow IE to grow the element, but all other browsers will see the height as a fixed height and won't grow beyond that height.
you could use: min-height:100px; height:auto !important; height:100px;
which will allow good browsers to over-ride the fixed height, or you can just set height in an IE only stylesheet using Conditional comments - whichever way you choose will depend on how you feel about validation...
There's a few innacuracies I believe in this article:
height will act like min-height in IE6 because IE6 will expand an element's height to accomodate longer content, but the same's not true of min-width/width. If you set a width on an element, in IE6 it'll always be that width, it won't expand to accomodate larger windows, which is the intended purpose of using min-width.
Like Bobby Jack, I've never had to add zoom:1 to pos:rel elements to overcome bugs, so not sure I'd recommend that.
And as far as zoom: 1 not validating, in most cases, triggering hasLayout can be achieved by giving an element a dimension instead.
Adding display: inline to floated elements is only required to fix the double-margin bug AFAIK and then only when that element has a left or right margin. While it doesn't hurt to add display: inline, I don't think it's necessary to add it to every floated element in a layout.
A couple of other ones that I come across often are:
If you set anchors in a list to display: block (to achieve background change on hover effects), you need to make sure you also give the anchors a dimension or they'll be vertically spaced out much more in IE6.
If you want to attach a rule to (for example) a:hover span, you also need to trigger the action in IE6 by adding a rule to a:hover (whether you need a style on the anchor or not).
Most of the other bugs affecting IE6 are covered at Position is Everything.
Very true, shame I overlooked that!
as in height:1%? Could be, but I don't see much difference with using zoom:1
Very true, but I hope to clarify the reason for listing these particular bugs and fixes later today :)
Not necessarily. If you're working on a fixed width layout, just work out what the actual width of the element is (using Firebug for this is very useful) and use that in your main stylesheet, no need for * html or conditional comments.
Hmm, not my preferred way of working. I've had several projects where the goal was to widen a design and when it is implemented like that it's a really dull and timeconsuming task.
I always aim to set as little actual widths as possible. Usually I just set one on my main container, and a set to determine the width of total-1 columns. That's about it. Change of of those two and the whole design will nicely adapt.
height: 1% is a better solution that works and validate
Thanks for this post, it just saved me a lot of time fixing a random IE6 bug. I am most grateful.
Just had to thank you for sharing all of this info. It saved me a lot of time!
Thank You!!
I have a great idea. All those in the web design/dev arena decide on a date when we all stop using ie6. It will be a unified push to get rid of the enemy. I think we have pandered to its oppresive regine far too long, lets stand up for "ie must die day"
You mention this under 'fix position:relative', "The only reservation here is that zoom:1 is best not used on inline elements, as they will start behaving like block elements."
You're statement is in fact wrong. Adding zoom:1 to an inline element is will make it display:inline-block.
The following will add display:inline-block across all browsers:
display:inline-block;
*display:inline-block;
zoom:1;
posted by roydukkey
Hey Roy, do you have more information on this? If this is true it would actually be a very interesting technique to mimic inline-block in IE. On the other hand, whenever I place a zoom:1 on an inline element it does behave like a block element (taking up as much horizontal space as possible), so I don't see how this can be inline-block behavior.
@Niels I've put something together for you. Check it out and let me know if you have any question.
http://www.roydukkey.com/display-inline-block-zoom/
posted by roydukkey
Nice information, I really appreciate the way you presented.Thanks for sharing..
Roydukkey, I'm not getting this to work in all browsers. Could you explain a little more. I'm kind of new at this (sorry) but really interested. Niels did you get it to work?
Actually the correct answer is: Adding zoom:1 will add hasLayout to the inline element. The additional display:inline will give it display:inline-block behavior. That is true for ie5.5 to ie7.
Forgot to say ... Really enjoy your blog
* required fields