Forum Moderators: not2easy
Two things have always bugged me about the various IE bugs and their solutions [positioniseverything.net].
Thesis
So, I've been pondering something... Is it true that IE has all these bugs (more seem to pop up every day), or are they all simply variations on the same theme? Maybe there's simply just one or two bugs, not tens or hundreds?
I will now present evidence showing that my reasoning seems to be correct. IE does not have an endless array of display bugs. Instead, there's just one!
The bugs
Let's take a look at some of the more famous IE bugs...
Peek-a-boo
We've all seen it -- content that magically appears/disappears/reappears, seemingly for no reason. The most common trigger involves floated elements.
Solution? Well, it's been proposed that
position:relativeline-heightheightUnscrollable content
An absolutely positioned element inside a relatively positioned element may cause the scrollbar not to appear.
Solution? The Holly Hack seems to work very well, simply because it assigns a height to the relatively positioned "wrapper"...
Duplicate characters
One of the more annoying bugs! It is triggered by two or more "non-content-generating" elements immediately following a floated element. These "non-content-generating" elements can be pretty much anything that doesn't generate content:
<!-- regular comments -->
element with
display:none3px jog
Eww! Another of those nasty ones. Text adjacent to a float gets indented by 3px, but only for the length of the float. Once the float ends, so does the bug.
Solution? Add dimensions to the element next to the float. This is, however, not always extremely practical, or even possible. And, adding the dimensions magically triggers other bugs. Go figure!
Escaping floats
This bug is a mess! Floated elements "run over the edge" of its container, the container only holds the last row of floats... and... and... (who builds a layout like that anyway?)
Solution? The Holly Hack again comes to the rescue, and performs quite well.
Creeping text
Hmm... Weird! This bug is triggered by nested elements, each with certain identical styles applied. This one you have to see for yourself!
Solution? Apply a bottom border (which may not always be desirable) or "avoid the trigger combo altogether" (well, duh!).
Doubled margin
A float with a margin in the same direction as the float (left margin on left-floated element, right margin on right-floated element) triggers the bug which, as the name indicates, doubles the assigned margin. Very frustrating!
Solution? Up until recently it was thought to be impossible to solve, but now it's been found that simply adding
display:inlineDuplicate indent
Essentially identical to the above bug... but for some reason listed as a separate bug(?). The bug identifies itself the same way, the solution is the same... (Maybe they're brothers?)
Summary
As you can see, the solutions are way different for each bug, and may trigger additional bugs. Other times, the solution is simply not an option because of layout etc. Furthermore, certain hacks/fixes (Holly Hack for example) depend on rendering bugs currently present in IE, hacks that work today, but may well no longer work in the next generation of IE.
Thought process
So, all this got me thinking -- there must be an easier approach? After all, these are all various display bugs that... Wait a second! "Display" bugs? So, perhaps the display property may hold the fix? The fix for the doubled margin bug may not have been a coincidence!
And, in fact, it appears that the
displayMagic
The solution for the duplicate characters and doubled margin problems is, as stated above, to simply specify
display:inlineWhat about the other bugs? Does
display:inlinedisplaydisplay:inline-blockdisplay:inline-blockVoila!
Why are these solutions superior? Simply because if IE finally gets its act together, they will do no harm! No need to worry about whether the fix will break in compliant browsers.
Plus, you don't have to memorize an array of fixes! Simply use the
display<added>
inline-block is not a valid value in current recommendations, even though it has made its way into the candidate release for CSS2.1
The fact that IE already supports a brand new feature (knowing their past history of not supporting recommendations until much later, if at all) obviously only means one thing -- they were already using these types of elements, which in of itself explains why the property works as a fix.
Maybe MS themselves pushed for this addition to CSS2.1? Who knows? :)
</added>
[edited by: DrDoc at 3:54 pm (utc) on July 21, 2004]
-B
Uh... Does this mean I can't clank down on IE anymore? >_>
<_<
Awesome post Doc, you da man!
There is a bit of a gotcha to this method, though. display: inline-block; is NOT valid CSS and will cause your CSS file to fail the W3 CSS Validation. Of course, if you are doing useragent-switching on your CSS file, you can always just shoot that information to IE within the CSS file or in an alternate file.
Furthermore, certain hacks/fixes (Holly Hack for example) depend on rendering bugs currently present in IE, hacks that work today, but may well no longer work in the next generation of IE.
Luckily:
1. We won't have to worry about this for a LONG time... namely around Longhorn time (at least according to MS' present statements). We all know MS will probably do an IE update before then, though.
2. If any display hacks are deployed widely enough, MS will include them in newer versions of IE, probably with a Quirks2 mode or something like that, based on doctype switches.
If any display hacks are deployed widely enough, MS will include them in newer versions of IE
Groundbreaking post, Doc.
If any display hacks are deployed widely enough, MS will include them in newer versions of IEDoesn't this imply that Microsoft has a desire to be helpful and responsive to designer needs? Something which it's track record of proprietary code and standards ignorance does not play out.
Nope. It means that Microsoft wants to ensure that EXISTING sites work for end-users, otherwise IE would *look* broken. They still won't care about web developers.
display: inline-block; is NOT valid CSSI believe you are incorrect...
[w3.org...]
The W3C CSS Validator says otherwise:
"Invalid number : displayinline-block is not a display value : inline-block"
What does this mean?
UAs are allowed to implement features in a Candidate Recommendation in order to give feedback to the working group on how well these features work. Any UAs not supporting features of a CR can not be considered broken, non-compliant or lazy.
PS: It can be argued that some of IE's rendering flaws come from its complete support of the col and colgroup elements.
<style type="text/css">
#cont {
float: left;
display: inline-block;
}
#cont div {
display: inline-block;
}
#left {
float: left;
width: 200px;
}
#right {
float: right;
width: 200px;
display: none;
}
</style>
<body>
<div id="cont">
<div id="left"></div>
<div id="right"></div>
</div>
Guess I just need it spelled out a bit better exactly what inline-block "does" to the element it's applied to. I read the W3C specs and couldn't see much difference between display:inline-block and a floated element. Maybe I'm missing something on how this technique is supposed to be used.
Great thinking though, DrDoc. Excellent line of reasoning, to determine that many of IE's bugs are really just one! (Or at least can be fixed with a single "hack".)
WTG.. this is the most innovative case of thinking laterally about IE display problems I've seen in ages..
I love it :)
Suzy
The inline-block value seems to trigger the hasLayout behavior, which is why it fixes all the bugs the Holly hack does. I also found that this method did affect Op7, so it's not really harmless without a hiding hack. That stands to reason, since that value is meant to make a box behave like an inline element on the outside and a block box on the inside.
Darn it, I really thought this was going to cure the 3px bug without the hasLayout problem. Oh well.
display: inline-block is valid for CSS2.1, which is a Candidate Recommendation.
Good point. I wasn't aware of that. I would guess that's why it isn't in the validator yet, too.
Now can you get to work on the lack of min-width support? ;)
That was a great post. Anything that helps reduce the number of hacks is to be applauded.
This sort of thing is the BEST reason for subscribing here! Thanks. Flagged....
[msdn.microsoft.com...]
Also, it fails to do this in IE5/win, as with "zoom", so I regret to say that nothing new has been achieved here. Still, it's nice to have alternate ways to trigger "layout" in IE, since unknown changes may occur in the Longhorn release. With several methods it increases the odds that we can avoid a total train-wreck, hack-wise, when that happens.
Now the debate is which method to use, to force "layout" in IE. Since this new 'inline-block" method must be hidden just like the Holly hack, and since the HH works all the way back to IE5, unlike "inline-block" and "zoom", it would appear that the Holly hack is indeed the way to go.
I'm sorry to have to shoot DrDoc's method down. I too have gone thru just this sort of thing, and hearing that my great new bug fix was not so great was most deflating. But IE doesn't care about us, it's quite nasty enough to cause great pain at any time.
BTW, I would like to know what the negative side effects of the HH are. I have never noticed any. (?)
