CSS

Internet Explorer 5.x is famous for its broken box model. According to CSS definitions padding and border is supposed to be applied outside the box, not inside it.

To illustrate:

border: 20px solid; padding: 30px; width: 300px;

The above code should result in a total width of 400px.

border + padding + width + padding + border = total
20 + 30 + 300 + 30 + 20 = 400px

However, in IE5.x the total width is only 300px, with an inner width of 200px

width - padding - padding - border - border = total width in IE5.x
300 - 30 - 30 - 20 - 20 = 200px

Now, this is not the only problem with IE5. It also has a built-in parsing error. For example:

width: 400px; voice-family: "\"}\""; voice-family: inherit; width: 300px;

IE5 would prematurely abort reading the rule when it encounters this string:

voice-family: "\"}\"";

Other browsers will ignore the line. The voice-family is reset on the next line after which the "real" width is served to non-IE5 browsers.

If you use this hack, IE5 will render the div with a proper height and width. It works, and it doesn't cause any problem in any other browser.

Great! That should be the end of the story, right?
But it's not, and for three very good reasons:

1) This is not proper CSS code, and should therefore be avoided. The code will not validate.
2) Since it is not valid code, and since it is "tampering" with a CSS rule used by screen readers it might make it difficult, even impossible, for a visually impaired visitor to use the page. It might even cause the screen reader to not function properly.
3) There are other ways

Never ever resort to using a "hack" if there are other ways. ;) There are two competetive workarounds for this IE5 bug.

1. Do not apply size and padding at the same time

A simple way to avoid this IE5 rendering problem is to simply not apply padding to a sized div.

Instead of

<div style="width: 300px; padding: 30px;"> Content content content... </div>

consider

<div style="padding: 30px;"> <div style="width: 300px;"> Content content content... <div> </div>

As you can see, in the second example width is applied to the content div. Then we have an outer div to which padding is applied.

Since no padding is applied to the inner div, it will render 300px wide in all CSS capable browsers.

And, since padding is applied to the outer div, but no width, it will adjust to the inner div's size before applying padding.

Wonderful! We have just solved the problem without using the hack!

But, there is another issue - we have now created an unnecessary div. If IE5 didn't have a broken box model we would only need one div, not two. Hence, even though this method solves the problem, it also causes code bloat.

Sure, if you only have one div - no big deal. But consider thousands of documents with two or three divs on each page. That is a lot of extra code for no reason!

2. Conditional Comments

Now, what is this? It is simply one of many Microsoft-specific proprietary codes. For example:

<!--[if IE 5]> This will only be displayed by an IE5.x browser <![endif]-->

A non-IE browser, or maybe I should say "any browser but IE5.x", will ignore the content between the tags. The content can be anything - text, code. This means we can serve an additional/separate style sheet to IE5 in the following manner:

<link rel="stylesheet" href="styles/basic.css" type="text/css"> <!--[if IE 5]> <link rel="stylesheet" href="styles/ie5.css" type="text/css"> <![endif]-->

The basic style sheet contains the "real" width, while we serve IE5 an adjusted setting compliant with its broken box model.

(More information about Conditional Comments)

Conclusion

Even though Tantek Çelik's hack obviously works I strongly recommend using one of the above-mentioned methods instead, preferably the latter. Using Internet Explorer's Conditional Comments is a powerful way to serve IE browsers specific content. It is forward and backward compatible. It validates. It works! ;)

There is some irony to this, avoiding a hack by using proprietary code (the IE-only conditional comment), but your points are well taken.

Personally, I often use the hack because it keeps an intact code block with all the properties of a div in one place which makes code maintainence easier. And needless (except for IE5) divs within divs within divs. Dagnabbit, I might as well go back to *shudder* table-based layouts.

Sorry, this is a sore point with me. Seeing the elegance of CSS raped by bad browsers really gets up my nose. And the fixed background positioning bug in IE, don't get me started!

DE

I knew this really and have always avoided this hack, but your post has pulled together somethings that were already floating about in the grey matter and today I made my first page using the IE conditional statements..

ricfink what you say echoes my own feelings on this perfectly!

I always swore (well almost) when IE's Box model was mentioned, now instead of designing in IE and then making it work in other browsers I may change to NN (sorry Opera that overflow property is a nightmare! and I found a way to hide stuff from you as well) then add in the IE conditionals

;)
Suzy!

[edit]sp! ;)[/edit]

[edited by: SuzyUK at 11:44 pm (utc) on Feb. 21, 2003]

Glad to hear that suzyuk.
I thought I was doing something non-compliant somewhere.

Now I'm going to their site to complain!

Method #2 is just a browser sniffing hack that relies on a separately maintained stylesheet for it to work. Back in 1998, this would have been passible but a large part of the impetus behind the CSS-P movement is to eliminate maintaining separate style descriptions for each browser. Every style change you make to the master CSS in this example needs to be replicated in your IE5x file, so much for on the fly theme selection. The only thing this sniffer approach has over a javascript sniffer is that it doesn't alienate users without javascript. It would be a far stretch to call Method #2 a vast improvement over the box model hack.

Method #1 is morepassable, although it creates more DIV soup. I personally prefer the box model hack to more DIV soup. It makes my layouts easier to read and maintain. It also keeps me far from imitating table based layouts with multiple tables embedded within eachother to achieve the same effects.

The box model hack does validate if you set media type to all. I know you do not want to pass aural values to a print style sheet so you would have that to deal with if you understand what I am talking about.

I have also used aural browsers on each of my large CSS-P sites and not had a single one croak where I initiated the box model hack. Before you bry wolf about readers not being able to cope, try them.

Granted the box model hack is a hack that none of us wish we had to deal with. I just would like to temper the arguement with some differing opinions.

Ishmael

To answer some questions .. No, I have never experienced any problems with screen readers. But there's always the "what if" question lingering. We don't know what will happen in the future.

As for the Conditional Comments. You really don't have to maintain two separate style sheets. In fact, the only thing you would have to put in the IE5 CSS is an adjusted width to make up for the broken box model.

Does this require manual editing? No, it doesn't! Just use an expression.

div {
width: expression(document.body.innerWidth-200);
}

That would, for example, give you a width equal to the inner width of the window minus 200 pixels.

There are limitless possibilities :)

However, I'm not saying that you're wrong, taoofbean .. or anyone else for that matter. Just wanted to show that there other options.

The logical thrust of your opinion seems to be that by using Tantek's hack within a single style sheet you are somehow eliminating having to maintain separate style descriptions for each browser. But that's not the case - the browser requires what it requires no matter if you put it within a single style sheet or ten.
The separate style descriptions are still there, you've just included them in the same style sheet.
Nothin' noble.

More troubling is that instead of clearly labeling those separate style descriptions by isolating them within their own clearly named style sheet, you're mixing them in along with the rest of the standards-compliant style descriptions. Further, these "special" descriptions (which, remember, will one day be obsolete) are labeled only by a cryptic hack that might be unfamiliar to others who need to make changes to the site.

From a managerial point of view, Tantek's hack sucks and under many easily imaginable real-world scenarios it's not a far stretch at all to say that "Method 2" is a vast improvement.

And then there are the other downsides:

While I commend you for your thoroughness in testing with aural browsers, I think you will still agree that the hack is at least an invitation to trouble. And we both agree that the hack has no place in a print style sheet.

Now, I'm not quite sure exactly what you mean by "on the fly theme selection" but I don't quite see how it's necessarily precluded by using conditional comments along with a separate style sheet.

Here's my bottom line:
A time will come when IE 5x will disappear and I ask myself, at that time, what am I obligated to do about those IE5x style sheets and those conditional comments?

The answer is "nothing".

There is no downside whatsoever that I can see.

well we are gong to have to agree to disagree on using conditional comments or equally conditional {expressions} instead of the Box Model Hack. At this point in time, I am firm in my resolution that using markup on my initial page that sniffs for browsers is a bad thing. Conditional expressions and comments always need to be updated whenever a change has been made to the structure of the default style. I just happen to be more comfortable with my browser quirks within the style, not the core document.

Why I think the box model hack is somehow different than the Conditionals that rely on proprietary browser code is that you are taking advantage of a mistake Microsoft made with the box model hack. The conditional approaches take advantage of intentional non-standard proprietary browser language and I feel reaffirming of Microsoft's affection with proprietary browser standards is what got us in this mess to begin with.

The box model hack is simply a sniffer within the master style. Managing that sniffer to me is much less hassle than a separate conditional style. I simply /*comment*/ the style to let future authors know what I have done. Beyond a website blog, a complicated CSS-P template needs a lot of these such workarounds commented so that I don't inadvertently break the structure later on. Hacks for Mozilla, Opera, and IE abound in style sheets. The Box Model Hack is simply one in a line of these hacks that have to litter a complicated style sheet with these current browsers. One more comment within the template complicates nothing for me. However, when I routinely develop around five separate css sheets for a complex site (this includes themes, structure, print, and aural), having a separate subsection of IE 5x styles (win and mac) is my straw breaking the camel's back.

For purity's sake, maybe we all need to move to the DIV soup method. No more quibbling about whose hack is better.

But after this hack, we would just have to focus more on the others that need to be done. After all of these years we are still stuck with this crap, different crap but crap nonetheless.

regards:
Ishmael

What kind of hacks are you talking about? No matter how complex I make my style sheets, I never have to implement hacks for Gecko-based browsers or Opera.

As far as maintaining an IE5 hack for Windows and Mac separately - that's not necessary.

I agree with you on two points though: if the style sheets are easier to maintain, using Tantek's hack, then why not? Also, no matter which method one decides to use, we can't ignore the fact that they really shouldn't be necessary.

After all of these years we are still stuck with this crap, different crap but crap nonetheless.

Well said! ;)

So let each person use a method that will cause him/her the least problems in the future.

I started a thread with the same title avoiding Tantek Celig's box model hack last summer and received some interesting insight from our now MIA CSS guru papabaer.

I opted to go with the <div> soup method of working around this. Yes, it has contributed to code bloat somewhat but I'm still so happy about the reduced page size compared to tables it hasn't been an issue. ;) Thanks to this thread I am going to take another look at Conditional Comments.

Yeah, I remember the thread from last summer. It sort of inspired me to take another look at the current options, update it with new insight ..

Well, at least that's what I attempted to do ;)

All three methods have been thoroughly discussed previously, just not in the same thread.

Anyone who's interested in older discussion can make a site search for "tantek".