Welcome to WebmasterWorld Guest from 54.234.38.8

Forum Moderators: not2easy

Message Too Old, No Replies

Taking on IE bugs

IE does not have multiple CSS bugs -- just one or two

     
7:50 am on Jul 21, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member drdoc is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:Mar 15, 2002
posts:6807
votes: 0


Background

Two things have always bugged me about the various IE bugs and their solutions [positioniseverything.net].

  1. Each bug required a slightly different fix, which makes it cumbersome and hard to remember exactly which fix goes with which bug, and whatever side effects each "fix" may have.
  2. For obvious reasons, the "Holly Hack" has always been upheld as the ultimate fix, and so quite understandably. It appears to be the solution to most of the bugs, even though it also has negative side effects.

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:relative
solves the problem... which it does. But, humm... what if the element is absolutely positioned? Well, it's also been said that
line-height
...
height
... Hard to keep track of them!

Unscrollable 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:none

<input type="hidden">
<script></script>
etc.
Solution? Nothing substantial... Various cumbersome, and ultimately limited, hacks, none of which are very convincing.

3px 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:inline
to the floating element solves the problem.

Duplicate 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

display
property holds the answer and solution to all of the above bugs. Finally, no need to memorize different bugs or different solutions, hacks, their pros and cons. There is just one bug, and one solution!

Magic

The solution for the duplicate characters and doubled margin problems is, as stated above, to simply specify

display:inline
for the floated element. The fact that the display property clears the bug is really interesting seeing how it is really supposed to do, well, nothing! (For more information on float in combination with display, please consult W3C [w3.org])

What about the other bugs? Does

display:inline
work on them as well? Well, not quite... But, a non-existing value [w3.org] for the
display
property does -- inline-block! For the 3px jog and creeping text problems, simply apply
display:inline-block
to the element itself. For the peek-a-boo and unscrollable content problems, apply
display:inline-block
to the containing element (=parent/wrapper).

Voila!

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
fix each time. After all, that's what was broken in the first place ;)


<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]

8:17 am on July 21, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:May 30, 2003
posts:728
votes: 0


DrDoc, whatever they're paying you, it aint enough. That's some very good thinking.

-B

8:25 am on July 21, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Jan 13, 2003
posts:1240
votes: 0


thanks Doc! excellent summary and a definate 'flaggable post'
9:22 am on July 21, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Dec 5, 2002
posts:1318
votes: 0


A groundbreaking post! Perhaps IE isn't broken at all, just requiring a stricter use of 'display'.
9:36 am on July 21, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member blobfisk is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:Feb 25, 2002
posts:3185
votes: 0


Top notch - great thread!
12:50 pm on July 21, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Mar 22, 2001
posts:2450
votes: 0


Cheers, DrDoc!
12:57 pm on July 21, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Nov 13, 2002
posts:818
votes: 0


Awesome post DrDoc! This is definitely one for flagging and for the library.
1:18 pm on July 21, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Mar 14, 2004
posts:1181
votes: 0


Nice work, DrDoc.
1:19 pm on July 21, 2004 (gmt 0)

Junior Member

10+ Year Member

joined:May 11, 2003
posts:172
votes: 0


...

Uh... Does this mean I can't clank down on IE anymore? >_>
<_<

Awesome post Doc, you da man!

1:26 pm on July 21, 2004 (gmt 0)

Full Member

10+ Year Member

joined:Sept 25, 2003
posts:308
votes: 0


When are you getting your honorary doctorate? Many thanks for your efforts.
1:34 pm on July 21, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Dec 5, 2002
posts:1562
votes: 0


bookmarked. Very good summary! Thanks!
1:36 pm on July 21, 2004 (gmt 0)

Full Member

10+ Year Member

joined:Feb 23, 2003
posts:207
votes: 0


Nice post, DrDoc! I'm gonna hafta start playing with these NOW!

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.

1:46 pm on July 21, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Dec 5, 2002
posts:1318
votes: 0


display: inline-block; is NOT valid CSS

I believe you are incorrect...

[w3.org...]

A nice demo page here for non-IE users:

[w3.org...]

[edited by: Hester at 1:56 pm (utc) on July 21, 2004]

1:55 pm on July 21, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:June 6, 2004
posts:2239
votes: 0


If any display hacks are deployed widely enough, MS will include them in newer versions of IE

Doesn'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.

Groundbreaking post, Doc.

2:51 pm on July 21, 2004 (gmt 0)

Full Member

10+ Year Member

joined:Feb 23, 2003
posts:207
votes: 0


If any display hacks are deployed widely enough, MS will include them in newer versions of IE

Doesn'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.

2:54 pm on July 21, 2004 (gmt 0)

Full Member

10+ Year Member

joined:Feb 23, 2003
posts:207
votes: 0


display: inline-block; is NOT valid CSS

I believe you are incorrect...

[w3.org...]

The W3C CSS Validator says otherwise:

"Invalid number : displayinline-block is not a display value : inline-block"

3:06 pm on July 21, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Oct 23, 2002
posts:1052
votes: 0


Awesome, DrDoc. Who would have guessed that a Swede could make me proud of what Scandinavians show the world? ;) (And make me admit it in public.) One of these days I will take a close look at my CSS files while having this thread open.
3:14 pm on July 21, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Apr 18, 2003
posts:827
votes: 0


display: inline-block is valid for CSS2.1, which is a Candidate Recommendation.

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.

3:39 pm on July 21, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:June 9, 2003
posts:1908
votes: 0


So what if you want to use display:none, or you really need to use either display:block or display:inline? Would something like this work:

<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".)

3:47 pm on July 21, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Mar 11, 2003
posts:1375
votes: 0


Nice work, DrDoc, great thinking!
3:48 pm on July 21, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member suzyuk is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:Oct 1, 2002
posts:5199
votes: 0


Whoa Doc! Superb Post

WTG.. this is the most innovative case of thinking laterally about IE display problems I've seen in ages..
I love it :)

Suzy

3:56 pm on July 21, 2004 (gmt 0)

New User

10+ Year Member

joined:May 22, 2004
posts:7
votes: 0


I'm not so sure this fix is doing anything new. In my test, "display: inline-block;" behaves exactly like the Holly hack. Specifically it moves IE into its odd float model. A truly useful 3px fix would not do this.

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.

4:10 pm on July 21, 2004 (gmt 0)

Full Member

10+ Year Member

joined:Feb 23, 2003
posts:207
votes: 0


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.

4:52 pm on July 21, 2004 (gmt 0)

Preferred Member

10+ Year Member

joined:May 16, 2003
posts:592
votes: 0


Thanks DrDoc, this thread is getting flagged :)

Now can you get to work on the lack of min-width support? ;)

7:50 pm on July 21, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Oct 21, 2002
posts:1051
votes: 0


DrDoc,

That was a great post. Anything that helps reduce the number of hacks is to be applauded.

9:42 pm on July 21, 2004 (gmt 0)

Preferred Member

10+ Year Member

joined:Sept 24, 2002
posts:364
votes: 0


Good work DrDoc, much appreciated.
10:32 pm on July 21, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Apr 19, 2003
posts:1747
votes: 0


Outstanding. What a masterful post, easy to understand, completely clear. And what a GREAT example of creative as well as logical thinking processes!

This sort of thing is the BEST reason for subscribing here! Thanks. Flagged....

11:57 pm on July 21, 2004 (gmt 0)

Preferred Member

10+ Year Member

joined:Apr 13, 2004
posts:428
votes: 0


Wow. Great work. I'm glad you didn't post this in the subscribers forum ;)
12:36 am on July 22, 2004 (gmt 0)

New User

10+ Year Member

joined:May 22, 2004
posts:7
votes: 0


It actually appears that MS by design allows "inline-block" to set the hasLayout property to "true".

[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.

5:43 am on July 22, 2004 (gmt 0)

New User

10+ Year Member

joined:May 22, 2004
posts:7
votes: 0


Wow, now I see! Forcing "layout" on a critical box really does fix all those IE bugs! I will have to update those pages to reflect this. That Holly hack is even more versatile than we thought. When I did that "Creep" demo the Holly hack was not yet known, but why did I fail to try it on the duplicate characters bug?! I must be slipping bad.

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. (?)

This 45 message thread spans 2 pages: 45
 

Join The Conversation

Moderators and Top Contributors

Hot Threads This Week

Featured Threads

Free SEO Tools

Hire Expert Members