homepage Welcome to WebmasterWorld Guest from 50.17.107.233
register, free tools, login, search, subscribe, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor
Home / Forums Index / Code, Content, and Presentation / CSS
Forum Library, Charter, Moderators: DrDoc

CSS Forum

This 45 message thread spans 2 pages: 45 ( [1] 2 > >     
Taking on IE bugs
IE does not have multiple CSS bugs -- just one or two
DrDoc




msg:1190383
 7:50 am on Jul 21, 2004 (gmt 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]

 

bedlam




msg:1190384
 8:17 am on Jul 21, 2004 (gmt 0)

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

-B

benihana




msg:1190385
 8:25 am on Jul 21, 2004 (gmt 0)

thanks Doc! excellent summary and a definate 'flaggable post'

Hester




msg:1190386
 9:22 am on Jul 21, 2004 (gmt 0)

A groundbreaking post! Perhaps IE isn't broken at all, just requiring a stricter use of 'display'.

BlobFisk




msg:1190387
 9:36 am on Jul 21, 2004 (gmt 0)

Top notch - great thread!

volatilegx




msg:1190388
 12:50 pm on Jul 21, 2004 (gmt 0)

Cheers, DrDoc!

photon




msg:1190389
 12:57 pm on Jul 21, 2004 (gmt 0)

Awesome post DrDoc! This is definitely one for flagging and for the library.

Rambo Tribble




msg:1190390
 1:18 pm on Jul 21, 2004 (gmt 0)

Nice work, DrDoc.

Wertigon




msg:1190391
 1:19 pm on Jul 21, 2004 (gmt 0)

...

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

Awesome post Doc, you da man!

chadmg




msg:1190392
 1:26 pm on Jul 21, 2004 (gmt 0)

When are you getting your honorary doctorate? Many thanks for your efforts.

ThomasB




msg:1190393
 1:34 pm on Jul 21, 2004 (gmt 0)

bookmarked. Very good summary! Thanks!

CritterNYC




msg:1190394
 1:36 pm on Jul 21, 2004 (gmt 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.

Hester




msg:1190395
 1:46 pm on Jul 21, 2004 (gmt 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]

createErrorMsg




msg:1190396
 1:55 pm on Jul 21, 2004 (gmt 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.

CritterNYC




msg:1190397
 2:51 pm on Jul 21, 2004 (gmt 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.

CritterNYC




msg:1190398
 2:54 pm on Jul 21, 2004 (gmt 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"

troels nybo nielsen




msg:1190399
 3:06 pm on Jul 21, 2004 (gmt 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.

drbrain




msg:1190400
 3:14 pm on Jul 21, 2004 (gmt 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.

MatthewHSE




msg:1190401
 3:39 pm on Jul 21, 2004 (gmt 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".)

mipapage




msg:1190402
 3:47 pm on Jul 21, 2004 (gmt 0)

Nice work, DrDoc, great thinking!

SuzyUK




msg:1190403
 3:48 pm on Jul 21, 2004 (gmt 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

Big_John




msg:1190404
 3:56 pm on Jul 21, 2004 (gmt 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.

CritterNYC




msg:1190405
 4:10 pm on Jul 21, 2004 (gmt 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.

Reflection




msg:1190406
 4:52 pm on Jul 21, 2004 (gmt 0)

Thanks DrDoc, this thread is getting flagged :)

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

HarryM




msg:1190407
 7:50 pm on Jul 21, 2004 (gmt 0)

DrDoc,

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

SethCall




msg:1190408
 9:42 pm on Jul 21, 2004 (gmt 0)

Good work DrDoc, much appreciated.

vkaryl




msg:1190409
 10:32 pm on Jul 21, 2004 (gmt 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....

Teknorat




msg:1190410
 11:57 pm on Jul 21, 2004 (gmt 0)

Wow. Great work. I'm glad you didn't post this in the subscribers forum ;)

Big_John




msg:1190411
 12:36 am on Jul 22, 2004 (gmt 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.

Big_John




msg:1190412
 5:43 am on Jul 22, 2004 (gmt 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 ( [1] 2 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / CSS
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About
© Webmaster World 1996-2014 all rights reserved