Future-proof your CSS with Conditional Comments

7 August 2008: It’s three years since I wrote this, and the browser landscape has changed considerably. A rewritten 2008 remix version is published on the Opera developer network: Supporting IE with conditional comments—please go there rather than read the article here.

The IE development team are calling on people to clean up their CSS hacks that might fail when IE7 is released, so I thought I’d tell you about how I did this for an emergency design I did for a punter a couple of months ago.

My plan wasn’t primarily to future-proof the code, but to remove as many css hacks as possible, as I’d been contracted to rewrite a small brochure site very quickly (a few hours), and hand it over to another developer whose experience and skill were unknown to me. The end result was to remove all but one hack. Another side-effect is (I believe) much better structured, more maintainable and more logical code.

What CSS hacks do

CSS hacks allow web developers to send different rules to different browsers, usually (paradoxically) to make each browser’s rendering of the site look the same. This is generally necessary as Internet Explorer 5 and 6 have many bugs, so gets “good” rules wrong.

There are two types of CSS hacks:

There are now a gazillion documented CSS hacks, but one of the most common css hack is a box model hack to get over the broken box model in IE5. It’s a parsing error hack, most of which is to fool different browsers into seeing the hack or not. For example, all the voice family shennanigans is merely fooling IE5 not to read any more of the rule, so not overwrite its overly wide dimensions:


#buttocks{margin:0; padding: 0 15px;
width: 194px; /*IE 5.5 width - Tantek hack */
voice-family: ""}"";
voice-family:inherit;
width: 164px; /*real width*/ }
html>body #buttocks{
width:164px;}

The second rule (“html>body”) is a “Be Nice to Opera” rule, because Opera would also stop reading at the voice-family crap and inherit the 194px, which we don’t want because its box model is fine. IE<7 doesn’t understand the child selector, so doesn’t bother with the “hug Opera” rule. When IE7 is released, this won’t break, because although it will read the Opera rule, that’s the width it needed anyway, so no damage done.

Except to the sanity of the poor guy who comes after me, who’s got to maintain all this stuff. It also offends my purist’s soul, polluting the css like this. Given that all this is to overcome deficiencies in Internet Explorer, wouldn’t it be superlovelygorgeous if we could have a good, valid, hackless stylesheet and an extra one flagged as “Hey! IE5! this is for you!”? Well, we can, using use Conditional Comments.

How conditional comments work

These are html comments, with a marker so that IE parses them, and you can use them to enclose any html code – including the linking of a stylesheet. They were introduced in IE5 for Windows, so can’t be used to target previous versions of IE. The best thing is that, because these are html comments, they’re invisible to all other browsers, and they pass validation.

Here’s the syntax I use to feed rules to IE5:

<link rel="stylesheet" href="styles.css" type="text/css" />
<!--[if lt IE 6]>
<link rel="stylesheet" href="boxmodel.css" type="text/css" />
<![endif]-->

The main styles.css has this simple rule:
#buttocks{margin:0; padding: 0 15px;
width: 164px;} /*see boxmodel.css for IE5 override */

and boxmodel.css – which is only served to IE5 – overrides it thus:
#buttocks{width: 194px;} /*other rules in styles.css */

No confusing voice-family hacks or Be Nice to Opera rules! Huzzah!

IEbugs.css – correcting the main bugs and IE6 and earlier

A lot of css hacks are to feed rules to IE6 and below to compensate for the lack of many important features of modern web development, like PNG alpha transparency, CSS min-height and fixed positioning.

We can remove the hacks by calling a special override stylesheet called IEbugs.css for IE6 browsers or below, like this:

<!--[if lte IE 6]>
<link rel="stylesheet" href="IEbugs.css" type="text/css" />
<![endif]-->

Simulating min-height

Suppose you have a box that should never be less than 100px tall – perhaps you have a 95px background image that you always want displayed, but you can’t predict the quantity of content. In a standards-compliant browser, you’d use min-height, which doesn’t work in versions of IE less than IE7.

To work around it, we add a rule specifying the height (which works the same as min-height should). So if the rule in the main stylesheet says #box {min-height:100px;} that should be supplemented in IEbugs by

#box {height:100px; overflow:visible;} /*simulate min-height */

Give GIFs to IE, PNGs to the good guys

People who are more design-oriented than I am have long used graphics in the PNG format for their layouts as it allows them much more flexibility and loveliness. Unfortunately, IE6 doesn’t do PNGs properly, so people have used another hack to send an image that’s a GIF to IE. Here’s an example, using the * html hack that only IE understands:

#lovely {background: url(lovely.png) no-repeat;}
* html #lovely {background: url(lovely.gif) no-repeat;}

IE7 can do PNGs properly, and it will not understand the * html rule, in which case, it will receive the PNG sent by the first rule: all well and good. But as this is a rule for pre-IE7 browsers, it would be better sent to the doghouse of IEbugs.css.

Once banished, it won’t need the * html prefix, as the stylesheet is only being sent to IE<7, and will overwrite the main rule. So the main stylesheet keeps #lovely {background: url(lovely.png)no-repeat;} and IEbugs.css adds

#lovely {background: url(lovely.gif) no-repeat;}

Stopping long words destroying layout

Contrary to spec, IE allows very long words to expand a box widthwards – which can then easily destroy a layout if other boxes are floated right. This is particularly dangerous in areas where content can’t be rigidly controlled and tested, such as where blog comments are displayed, as someone can accidentally (or maliciously!) enter a very long word and totally nuke your design.

There’s an IE-specific css extension that will fix this, but prevent validation. Personally, I’m happy to use non-validating IE-only tricks to correct IE’s bad behaviour, particularly outside of the main stylesheet. Your purist levels may differ, of course.

Add this rule to the box that holds blog comments (or do what I did, and just add it to the body tag):

body {word-wrap: break-word;}

(I don’t know if IE7 will clean up this bug, so this may be better in a stylesheet for all IE browsers – see below).

Advanced IE6 bugfixing

If your design requires the ability to hover over any element, rather than just the a tag as IE currently restricts you to, you can add the csshover behavior in the IEbugs stylesheet:

body { behavior:url("csshover.htc"); }

(You can even go the whole hog and simulate IE7 with Dean Edwards’ JavaScript library, using conditional comments to pull in a JavaScript library.)

Another potential reason for an IE.css that I haven’t yet researched thoroughly might be to add IE Layout to certain elements, which can help stop many IE6 rendering bugs.

IE.css – serving styles to all versions of IE

Another good use for conditional comments is to seperate IE-only extentions to the CSS spec, as they’ll stop your main styles.css from validating (and aren’t necessary in a non-IE browser, so why send them?).

Such extensions would be filters on images, or coloured scrollbars.

Here’s the code for the head of the page:

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

If you don’t need these extensions, or you don’t care that you have stuff in your main stylesheet that won’t validate (and, in a practical world, there are absolutely no negative side-effects if you have) you can just leave this in the main stylesheet, although I prefer to completely seperate it out.

IE/Mac: the new Netscape 4

Not being gorgeous enough to be allowed to use a Mac, I haven’t tested this, but add it for completeness. I’m told that conditional comments only work for IE/ Windows.

If you need to feed rules to IE/Mac (which they say is as moribund as Netscape 4), there are hacks available, but you should consider importing a seperate IEMac stylesheet in your html header and keeping all IE/Mac rules in there:

<style type="text/css">
@import("IEMac.css");
</style>

The formatting of the import must be exactly as above. (Hat-tip)

Alternatively, you can keep your html header clean and import a separate IE/Mac set of rules from your main stylesheet via Tantek’s IE5/Mac Band Pass Filter, which is made out of fairy dust:
/*\*//*/
  @import "ie5mac.css";
/**/

Update 24 October 2005: Martin Belam, of the bbc website, analysed the 30 million requests for the BBC homepage in September 2005, and found that IE/Mac was used four times as much as Firefox/Mac, so maybe it’s a little too early to write IE/Mac’s obituary if yours is a real-world site (rather than Web Geek site).

Get yer code on, baby

To recap, here’s all the code for your header (you probably won’t need all of it)

<link rel="stylesheet" href="styles.css" type="text/css" />
<!--[if IE]>
<link rel="stylesheet" href="IE.css" type="text/css" />
<![endif]-->
<!--[if lte IE 6]>
<link rel="stylesheet" href="IEbugs.css" type="text/css" />
<![endif]-->
<!--[if lt IE 6]>
<link rel="stylesheet" href="boxmodel.css" type="text/css" />
<![endif]-->
<style type="text/css">
@import("IEMac.css");
</style>

Minimising http requests

Each stylesheet pulled in requires an extra http request, which can slow things down because the http gnomes get tired easily. In order to minimise these, you can combine all IE-facing hacks into a single IE.css, but would still need a version of the box model hack in here so IE5 gets the wider box. To send 164px width to IE6, and 194 to IE5, we need the voice-family jiggery-pokery from before, but don’t need the Be Nice to Opera rule. Here’s the code:

#buttocks{width: 194px; /*IE 5.5 width - Tantek hack */
voice-family: ""}"";
voice-family:inherit;
width: 164px; /*real width*/ }

A testing Gotcha

If you’re using multiple test versions of IE, don’t freak out when it appears that your boxmodel.css hasn’t taken. Whichever version of IE you fire up for testing, the conditional comment parser always believes that you are using the latest version installed. For those who are comfortable editing the Registry (about as nerve-racking as doing the splits naked over a live lobster, in my opinion), there is a fix (Hat-tip Simon Pieters).

Using conditional comments to hide something from IE/ Win

(Update 14 Nov 05). Roger Johansson notes Lachlan Hunt’s method of hiding something advanced from IE/ Win:

<!--[if !IE]>-->
do something; IE will ignore this, other browsers parse it
<!--<![endif]-->

This validates fine.

Conclusion

Although I’ve no religious objection to css hacks, we all have to be aware that pretty soon, a big new browser is coming to market. It’s good development practice to modularise your code, especially as within a year of release, IE7 will be the biggest browser and the hacks for old IE will become less and less useful.

I personally find development a lot easier if I can develop for Firefox first, with a “clean” stylesheet. When things start to take a turn for the unexpected, the css validator is a useful diagnostic tool. This utility is compromised when the stylesheet is full of IE-facing hacks. So I like to get everything working for a modern browser, and only then apply the hacks, using conditional comments.

Whether you believe that serving different stuff to different browsers is philosophically valid or The Work of Satan and All His Minions that will result in The Destruction Of The Web is entirely up to you. You may also feel that conditional comments, being IE-specific, are worse than css hacks. So be it; that’s your right. I’m a pragmatic purist, and this methodology works for me.

So let’s see it then, Mr Wilson

It’s fantastic that Microsoft are listening to us, and communicating with us. But the time has come now to let us play with the new Standards-aware IE7 beta and see what’s hot and what’s not – and feed it back, politely and constructively, to the IE team so the program gets better.

When you should use hacks, and not Conditional Comments

I haven’t had occasion to use the techniques so brilliantly devised by Alex Robinson in his article “In search of the One True Layout”, but I’d never ever contemplate doing it without CSS hacks. It’s complex enough for a third party to maintain or amend without various chunks of it being lopped out into seperate files. (Is it IE7-proof?, I wonder as an aside).

The conditional comments technique works very well if you have a relatively set design for your site. If you have a skinnable site, with loads of alternate styles and a stylesheet switcher, you probably need to continue with your css hacks. And that’s OK; most of your hacks should work OK with IE7. (Though it would be nice to test them, eh Microsoft?)

However, I’m talking about super-skinnable, to the level of something like the Zen Garden where the whole page layout radically changes. For stylesheet switchers that play with fonts and colours (probably for accessibility reasons, like red ant design do), I’d still recommend Conditional Comments, because IE isn’t so broken that it requires seperate stylesheets to override font and background colour declarations.

I’m making a similar stylesheet switcher for punter at the moment, using conditional comments. And one day, when IE6 has gone the way of IE4, I’ll just remove the conditional comment and, with a satisfied smile and a spring in my step, I’ll quietly delete IEbugs.css from my server. One day ….

50 Responses to “ Future-proof your CSS with Conditional Comments ”

Comment by Tunnuz

Damn! Was it difficult to code IE well from the beginning?! Agh … and now if I forget some hack in CSS I must explain to the customers that it wasn’t mine the error, but IE’s? And how to reply to the people I bored with the forward-accessibility and CSS, if now I have to change all? :|

Comment by Brad

Instead of the tried-and-true box model hack, could you use:

width:164px;width /**/: 194px;

I seem to recall that works as well (as far as IE6 ignoring the second one), and it takes up less bytes.

Comment by Maheshbabu.Interactive

Future-proof your CSS with Conditional Comments

Bruce Lawson’s article on
Future-proof your CSS with Conditional Comments
provides inshight on conditional commenting for browser specofic CSS files.
Continue Reading…

Comment by Bruce

@Jens – that’s true (and note that I don’t claim that Conditional comments are standards compliant), but CSS hacks are generally not compliant, either (although some may validate).

In a perfect world, all browsers would be standards-compliant, and no hacks or workarounds would be necessary. However, this isn’t quite the case.

The approach I describe here is putting hacks needed for the buggiest browsers in a quarantine, using a behaviour specific to that browser to work around the deficiencies of that browser. In that way, the markup will validate and the main stylesheet will also be clean, making bug-fixing simpler and future-proofing the code.

As I said, it’s a pragmatic approach that you can choose to use or not.

Comment by Maurizio Boscarol

I miss why conditional comments aren’t compliant. They are comments. No one care about comment content. We don’t break validation with conditional comments.

It’s not the comments that aren’t compliant (they in fact are), but IE that behave in a not “standard” way. But this is out of our control. IE isn’t standard also in the box model and in a few other things… so it also parses some form of tag inserted in comments: well, it’s up to it. We can take advantage of this or not, but conditional comment aren’t violanting any standard, and any syntax, as far as I can see.

Comment by Bruce

Hi Maurizio,
conditional comments violate the html spec which says, Information that appears between comments has no special meaning..

Because conditional comments *do* have a special meaning, it violates the spec. However, it validates (which is not the same as conforming to standards) because the validation robot can’t read a comment and work out whether it has special meaning or not. So it just automatically “passes” comments.

Personally, I agree that conditional comments violate the spec. But I don’t care that much, because so does IE and – unless you’re building a completely ‘undesigned’ minimally laid-out web page, you have to work round IE.

Personally, I prefer to violate the html spec with no validation errors, than have loads of css hacks and thus violate the css spec and also get loads of validation errors.

Your mileage may vary; the other opinion is perfectly valid.

Comment by Maurizio Boscarol

Hello Bruce. Thank for answering.

Well, I don’t want to have a hard discussion, and I respect your opinion. Most of all, I agree with your conclusion about having to face with incorrect browser behavior in a way or another.

My point is not for the sake of mere discussion: in Italy we have a strange law about accessibility in public sites, that force the code to be valid to be ok from a legal point of view. So in our country is important to agree what is valid (x)html and what break validation.

So the spec says: “Information that appears between comments has no special meaning”. Good. But what does that mean? That you *have* to write in the comment only things that are meaningless? Well, I don’t think! You use comments to remark the code, that is, to have some meaning that help you understand the code, for your commodity. This is good. And in that sense, the comment content should be meaningful!

I think that what specs mean is rather something like “information that appears between comment will not be parsed by user agent, so please don’t expect UA to do that”. The example is exactly about that: character entities are not interpreted as such!

So I understand that what you put in your comment is up to you, just don’t expect it will be parsed. And I don’t expect that.

If IE parses some content, that is a matter of IE. I can put in the comment what I want, knowing that IE does some strange things depending on some comments content.

But from a validation point of view, I’m ok whatever I put in the comment.

If not, the spec should have said “Please note that you’re not allowed to put in the comment code to be parsed”.

This is a problem of interpretation of the specs, and I think I’m right, but I know I could be wrong. In the wide wild world this is quite irrelevant. But for our law is important. I think that spec interpretation should be as unambiguos as possible when they change from tech raccomandation to legal constraint.

Maybe this is only a point that should alert people that make laws to be aware that technical specification should not be used as legal constraint per se. But this is another problem… :-)

I hope I explained my point. Thank you for your interesting site!

(disclaimer: I’m not a owner of a public site, and have no interest in one interpretation or another. I’m involved in methodology evaluation for the law and in teaching some good practices to public sites administrator, so I have just the need for clarity)

Comment by Bruce

Hi Maurizio-
can you point me to the law that requires valid code? I ask because, here in the UK our law (the Disability Discrimination Act) makes it illegal to discriminate against people with disabilities – but gives no technical details. It makes it illegal to place unreasonable difficulties in access.

Many people (including myself) believe that, if you meet WCAG priority 2, you are meeting the minimum requirements of the DDA, because priority 2 is defined: “Satisfying this checkpoint will remove significant barriers to accessing Web documents”.

One of the requirements of priority 2 is valid code (checkpoint 3.2: “Create documents that validate to published formal grammars.”)

But there’s nothing in UK *law* that says “You must write valid xhtml”, so I’d be interested to learn about an Italian law which requires it.

Comment by Maurizio Boscarol

Hello Bruce. Some pointers to let you examin the italian law and the related technical documents:

The law (4/2004);

The ministerial decree;

In contains a number of technical specification, including the 22 technical requirement for web site accessibility, mandatory for the public sites, including, at n.1, the xhtml strict valid:

Tech requirements;

There are also some other details, glossary, and a further level of specifications that include subjective analysis, with user testing, that isn’t mandatory, and, because of its cost, will have a spare chance to be followed. You can explore it by yourself.

If you’d like to know more, fell free to ask me, even privately. You’re welcome.

Anyway, I’d like to point out that the validation question is sometimes important for accessibility, and sometimes it isn’t. Tag soup is to be avoided, of course, but if I put a border attribute on most images in xhtml strict that will not result in a real accessibility barrier…

The problem arises when you have to respect that validation with tools (CMS, framework, etc) that are unfit at the moment. The public sites should change their instruments to fit the requirements? And are there such tools, at the moment?

And another problem is: what if I have a pre-existing set of tools, that I bought at high prices two years ago, or more, with the plan to use it in the next 5-7 years, and find now that those tools need to be changed but I haven’t the money to do that?

Validation is good, but, apart from defining what actually is a valid code (as in the example of conditional comment, we could have other potential disagreement on what it really is), it involves some practical and organizative questions (money, tools) that are critical in public administration. So I’d rather a strong pressure on cms and framework makers to build compliant tools in the coming years (like the WASP has done with browsers productor) than including the requirement as a law constraint right now.

This is only my point of view, and have no personal interest in the question, apart consulting and teaching (worth specifying once more, because this is not always the case here in Italy…).

Bye!

Comment by tedd

Hi Bruce:

You said: “I’m told that conditional comments only work for IE/ Windows.”

Well.. I’m not sure as to all they work on, but they don’t work for IE 4 on Windows 98, IE 5.1 Mac OS-9, or IE 5.2 Mac OS-X.

tedd

Comment by Bruce

Oops, sorry Ted. They were introduced in IE5 for Windows so don’t work in IE4. But very little does, really!

Have updated the article to make it clearer.

Comment by Gaz

Thank you Bruce for an imformative article. I have been considering for the last few days the question of whether I should gravitate more towards CSS hacks or IE conditional comments for current and future projects. And I think this article is the proverbial straw that breaks the CSS hacks back. IE conditional comments just seem a lot more stragiht forward to me.

Wouldn’t it be nice if we didn’t have to consider this issue at all.

Comment by Bruce

True, John – but in a way, that’s another hack; leaving out something I’d like to use in order to accommodate archaic versions of Internet Explorer. So I’d rather call boxmodel.css with a conditional comment and over-ride the size of the box, leaving my main stylesheet unhacked.

(Your mileage may vary; I’d rather do it this way, you’d rather apply margins to elements within a sized div. Each is fine).

Comment by scott

Bruce,

I prefer conditionals and avoid hacks. Reason: Hacks are like telling lies. You tell one, then you have to tell another to support the first, then you forget who you told what lie to and you’re life soon comes apart after that.

Better to be upfront and say, “Bozo, this rule is for you.”

Mind you, IE takes raps on the chin largely because they’re the big boy on the block. To be fair tho, they do have more legacy code and it was pretty nifty to come up with conditionals in the first place.

Which is why I’m here. Firefox understands my directive, but neither IE nor Opera do. I’ve feed the “fix” for IE, via a conditional, but I don’t know how to feed an Opera-specific directive. (Was hoping there was an Opera conditional, too).

Cheers,

-stk

Comment by Brian Darby

Hi Bruce,

I thought you might be interested in a problem that we’ve recently discovered with conditional comments..

We’ve had a number of clients that upgraded from Win98 to XP at various times in the past and then reported that parts of our website were broken when they viewed us (we use CC’s).

The problem is caused because the XP upgrade doesn’t update the version vector in the registry, when upgrading from Win98 IE5.0 (Only when upgrading from Win98 IE5.5 onwards.)

This means that users who upgraded from Win98 IE5 to XP IE6, still have a version vector of 5.0002

When their XP IE6 browser views a webpage with CC’s it will still behave as if it were IE5

Worth bearing in mind when using CC’s, unless users manually update their registries, they will be using an IE6 that still thinks it’s IE5 and their browser will process CC contents as IE5

Kind regards,
Brian

Comment by bruce

Thanks very much for letting me know, Brian.

How depressing. A microsoft-only hack to get over the limitations of a microsoft browser fails because the microsoft upgrade process doesn’t upgrade the microsoft Windoze Registry.

Sheesh.

Comment by Brian Darby

Hi Bruce, thanks for your reply.

Sorry, didn’t mean to depress you!

We are still looking into this and don’t yet know how common this situation is or how widespread the problem might be. I would be very interested to hear from anyone else that may have noticed this before. So far, this problem has occurred with three of our clients.

Cheer up!
Brian

Comment by Apie

Hi Bruce
Great article. i learned something and enjoyed it at the same time. love the quote about the lobster!

anyway, I am going with conditional comments instead of hacks since it will be infinitely more pleasureable to one day(as you say) delete my ie_insert_hatespeach.css file rather than know that there is a bunch of useless hacks in there.

I’m bookmarking your site!
Apie

Comment by Dave

Great article – goes a long way in helping to separate IE’s browser quirks, without having to muck up shared css content. I noticed a small typo in your article, which caused the site I was working on to bomb completely when left unresolved (only in IE browsers, of course!)

In your ‘Non-IE’ snippet:


do something; IE will ignore this, other browsers parse it

The last line should be:

(Notice the extra hyphens)

Cheers,

D.

Comment by Ryan

My personal preference is to stylize the body tag with…
body { font: normal 62.5% Verdana,Geneva,Arial,Helvetica,sans-serif; }

62.5% sets a page’s base text size to an equivalent of 10 pixels. Going forward I can then use something like…
.sitewrapper { font-size: 1.2em; }

It’s all a matter of semantics. For example 1.2em is basically 12px. Likewise 1.6em would be like 16px… 2.4em = 24px… and so forth.

I learned this trick from an ALA article three years ago. It’s always worked as intended. Here’s the caveat (if you were looking for one): this trick doesn’t work on older browsers like IE5.0.

Comment by Ryan

As a follow-up I highly recommend using em values in line-heights. Heights will automatically adjust based on whatever you set the font-size to be.

For example:

font-size: 1.4em;
line-height: 1.1em;

If you change the font-size to 1.5em you don’t need to change the line-height; it automatically scales up.

Comment by jim

Bruce,

Thanks for the reply. I am trying to make the mini-heihgt working for ie6. But for some reason, this doesn’t work for me.

in IEBugs.css

.labelContent {height:100px; overflow:visible;}

in products.css:

.labelContent {min-height:100px;}

and in .aspx header

Any idea?

Thanks,

Jim

Comment by jim

Oops,still missed one. Here is again. Sorry for the mess.

<link rel=”stylesheet” type=”text/css” href=”CSS/products.css” />
<!–[if lte IE 6]>
<link rel=”stylesheet” href=”CSS/IEbugs.css” type=”text/css” />
<![endif]–>

Comment by Braveheart

Good article Bruce, you have convinced me I am doing the right thing but with a couple of variations:

I start with a good document structure and outline for the content first linear layout.

Next @import ‘standards.css’; filters out version 4 and IE5Mac browsers who just get the linear layout.

I add the XML prolog to the top of my pages to force IE6 into quirks mode and use if lt IE 7 condition comments to @import ‘quirks.css’;.

If required, I add @import(“ie5Mac.css”) to keep that browser happy.

Occasionally, I might move some of the content styles to linear.css and link to this file to give older browsers a better presentation of their linear layout.

All my pages validate XHTML strict and CSS. I like the clean modular approach and it has always worked well for me.

It would be nice to have a more complete version of how all IE hacks can be moved into quirks.css. This could be a point of reference.

Thanks

Comment by srini

nice article obviously, well how about using the underscore hack for the min-height and min-width???
like

#box { min-height: 100px; height: auto !important; height: 100px; }

instead of

#box {height:100px; overflow:visible;}

Comment by bruce

Hi srini, I’m probably being a bit dense after my holiday, but what’s the advantage of what you propose? (I always dislike !important for browser hackery, as I find it makes the style sheets much harder to debug).

Comment by Goose

I am very impressed that a discussion that with a post in 2005 is STILL active because of MS silliness.. !!!

I have learn’t a lot and I have been doing this stuff for a while and have a times simply resorted to a table so I can get the damm thing up all the while feeling guilty about breaking the accessibility guidelines…

However if there was a definitive list of IE specific CSS screwups (that someone could point me too) that was clearly laid out that I could plan to pick my way around from the outset then i could die a happy web master !!!!

Comment by Bruce

Bram, Firefox won’t notice Conditional Comments. Neither will Opera, Safari or Chrome. It won’t even throw an error.

Only Internet Explorer cares about them.

Comment by dien thoai gia re giam gia

I also strongly recommend a screen protector such as the Zagg Invisible Shield.
The case is also easy to fit with a snap together design.
Some stores have big bulletin boards at the entrance which will allow
local businesses to post flyers or advertisements, just make sure you have a good way for people to
take your company name and phone number with them and this is usually done with slits along
the bottom of the ad that customers can just
tear off.

Also visit my webpage: dien thoai gia re giam gia