Skip to: Navigation | Content | Sidebar | Footer

Weblog Entry

Side-stepping IE

February 25, 2004

I’ve explored the MOSe (Mozilla/Safari/Opera enhancement) concept twice in the past: MOSe and MOSe Menus.

Let’s turn that telescope around. Let’s take a look at some of Internet Explorer for Windows’ biggest CSS deficiencies, and how you can use MOSe techniques or just plain old hacks to get around these problems.

Lack of Scalability

IE is the only modern browser on the market that doesn’t allow you to resize pixel-value text. The problem of course, is that we’ve long known that the px unit is the best way of ensuring cross-browser and cross-platform consistency.

So we have a choice: either don’t specify a font size at all and wait for the flood of emails from the 95% of the population that doesn’t even know they can change that, or break text scaling in Win/IE.

That is, we HAD a choice. Owen Briggs has since done a lot of work, and came to a pretty useful conclusion about font sizing:

I found you can make a nice ems stylesheet with <p> text at 1.0 em, and then downsize the whole thing by selecting size in <body> with %, like 76%. It’s simple, easy to change, and works for everything. Score 1 for late nights and coffee. Enjoy.

I’ve been using this method for a while, and it’s not quite as reliable as px, but it’s close enough for my liking.

Lack of support for min-width and max-width

Again comparing to all other browsers on the market, IE is the only one that doesn’t support the CSS2 properties min-width and max-width (which have been a standard since 1997, incidentally). These are incredibly useful for controlling larger areas of type, particularly when setting line length limits to aid in readability.

The trick to getting around min-width in IE is actually pretty easy. IE treats width as if it were min-width. By exploiting the fact that IE doesn’t support child selectors either (more on this later) we can create a simple bit of code that doesn’t allow a browser window to shrink below a certain size:

body {
 width: 700px;
html>body {
 width: auto;
 min-width: 700px;

Max-width is trickier, and involves a non-standard, proprietary extension. A clever fellow named Svend Tofte has written up the gory details, but consider yourself warned: using this will prevent your CSS file from validating.

The question begs: what about width? If IE treats it as if it were min-width, then how do we get the functionality of width? The answer hurts: we don’t.

Lack of Alpha Channel support for PNG

One of the more-often lamented problems is that IE doesn’t support the alpha channel of a transparent PNG. Fancy overlays and smooth transparency effects are only a pipe dream for, well, once more, all other browsers on the market. (Why would this be nice? Look!)

Luckily, as non-standard, proprietary hacks would have it, there is a solution. Our Swedish friends Erik and Emil tell us how to get PNG working in IE. Again: no validation for you if you choose to use it.

Lack of :hover Support

But :hover does work in IE, you say? On links, yeah, it has for quite some time. Even IE4 got that part right.

So what’s the problem? Take a look at Eric Meyer’s Pure CSS Menus in IE. The menu on the right has flyouts, but only in non-IE browsers. They’re pure CSS menus, and rely on :hover applied to list items, not links. Take a look at the menus dropping down from this very site, top right. Running IE? No dice.

This is a bit of an esoteric problem at the moment, but it’s becoming more and more central-focus as we’re exploring more seriously the advanced CSS that allows these sorts of menus.

Once again, hacks to the rescue! This time it’s Peter Nederlof bringing us the fix. In his whatever:hover article, Peter exploits the HTC file hack that got our PNGs working in the last example. Validate, non.

Lack of child and adjacent selectors

Last one for now. CSS2 introduced some powerful new selectors in 1997 that we’ve been able to use to cut down coding time, and exploit new and advanced CSS effects.

Well, that’s only half true since IE doesn’t keep up. In fact, because IE doesn’t understand these selectors, we’ve actually been using them to hide CSS from it. It’s been awfully handy, and out of this whole list, I’d prefer to see this problem addressed dead last. If we don’t have a reliable way of hiding CSS from Internet Explorer, then the web stays stagnant until IE gets better.

IE isn’t getting better. The web stays stagnant without these. I’m not really complaining about this point at the moment.

IE Bug Corner

We’d be in good shape if that were the end of it, but oh no, that’s merely the tip of the iceberg. Bugs! I haven’t even started to touch on the CSS bugs that IE induces. John and Holly over at Position is Everything have a great list of IE Bugs complete with workarounds in most cases, make sure to bookmark this one for later use.


This has been a brief overview of IE’s more glaring problems, with current solutions. None of these are ideal, but in an ideal world we’d never have to work around deficiencies. I haven’t touched on everything, I’m merely providing a starting point. Feel free to suggest more in the comments.

Reader Comments

February 25, 01h

Client-side scripting is inherently unreliable, and server-side negotiation dramatically reduces cacheability.

I’d agree with you if it was merely a case of user-agent sniffing, but it can be used for other purposes - as I mentioned, CSS signatures would no longer be needed. Another idea is different rules based upon the width of the browser:

@env[canvas-width < 500px] #sidebar {
display: none;

@env[canvas-width >= 500px] #sidebar {
float: left;
width: 15em;

February 25, 01h

re: dusoft

Why would the be so bad? We can say media=screen, why not env=”useragent:mozill” or env=”” or heck, go crazy, env=”domain:*,useragent:*ie*”

Wouldn’t that just be one more seperation of content/style/form that all of this css/xhtml/xml/xslt stuff is about?

February 25, 02h

Some guy wrote a comment in my blog that complained about the <abbr> tag not working in IE.

He linked to his site with a solution cleverly called abbr-cadabra.

He basically forces abbr into the document parsing tree. It doesn’t validate, but he says that is a failure of the validator, and is perfectly legal XHTML 1.1 Strict.

John Prevost says:
February 25, 02h

I’ve been using some javascript hacks for both PNG and min/max-width support in IE. The width script can be found at It’s not a perfect solution, but it helps if you’re going for a layout that stays in a small width on very wide displays but can deal with increasing font sizes. If the user has javascript disabled, the site remains usable as long as everything’s able to adapt to larger widths than you planned for.

The PNG script is an alteration of one I found somewhere (and I forget where.) I’d post a URL, but I don’t have a permanent home for it right now. The basic idea is to have an onload event replace all of the PNG images with the nasty filter:progid badness behind the scenes. This fails in uglier ways when javascript is disabled (you get fully opaque PNGs, most likely), and also has issues if you use font-relative sizes on images.

Ahh. Here’s a script that does almost the same thing:

Anyway, I so hope that the next IE gets these things right. Not to mention makes standards compliance mode the default instead of needing to be tickled into it. :)

February 25, 04h

Re: font sizes

For some time now, I’ve been using a double set of rules to specify a base font-size for the <body> element. A hacked WinIE rule that specifies the size in percentages (e.g. 75%) and then another rule for the MOS browsers that specifies the size in pixels (e.g. 12px).

Then I make sure that all my other font-size specifications use EM measurements (e.g. 0.92em) that build - either directly or indirectly - on the base font-size set for the <body> element.

I’ve found this method to be absolutely, perfectly reliable.

February 25, 04h

I hate it when the non-English characters in my name get screwed up by funky software. Ack!

Escaped HTML character-entities &acute; and &Ouml; to the rescue!

February 25, 04h

The key to get a validating website which is relatively cruft-free is to add conditional comments ( I’ve used them on my site and they work very nicely. Now all my IE-specific CSS hacks go into a seperate CSS stylesheet, in which eg. box-model problems and font-sizing issues are resolved. Also, by using the “behavior” CSS extension, you can easily link in the additional Javascript trickery which IE needs.
I’m quite surprised that these tricks are so little used (or mentioned). They’re great for forward-compatibility and they keep your CSS and HTML hack-free.

February 25, 05h

Any font-size solutions which make the assumption that the IE user still has thier base size set to the default 16px, and then uses a value like 76% to size it down is just asking for trouble.

If the user *has* changed their default size to something like 12px, then 76% of 12 is 9.12 – way too small for the average high-res monitor these days.

If they’ve set their default to 10, we’re now talking 7.6px – illegible for almost every font every invented.

There is a better way, but I’m only half way through testing… to be continued soon!

Moose says:
February 25, 05h

Jim Dabell:


“Another idea is different rules based upon the width of the browser:

@env[canvas-width < 500px] #sidebar {
display: none;


That is what the css3 media queries are for, and they are already supported by Opera.


February 25, 05h

I completely second Jeroen’s comments in regards to IE’s conditional comments… you can an entirely new IE stylesheet inside a special comment tag, and only IE will ever see it… sure, it’s a second stylesheet and a few extra lines in your , but it’s so simple… zero hacks required, and you can target each version (5, 5.5, 6) separately if needed.

No server-side or client-side scripting need at all – just a standards-compliant comment that talks with IE.

Jimmy Cerra says:
February 25, 08h

re: Jeff Minard

In a way, the user agent is a media type. However, I am also in favor of using an ugly-but-mostly-unique URI to prevent namespace conflicts between browsers (*cough* phoenix *cough*) and versions. Thus I’d much rather say media=”UA: screen, UA: alternative all” This seems to be the most flexible to me.

Séamus says:
February 25, 09h

Of course other selectors I would like to see support for :focus ( ) and :target ( ). There is a whole list of cool selectors that I would like to (:before, :after, etc).

February 25, 11h

Hello: I’ve also been using Briggs’ Magic-76 solution reliably.

Justin: If I understand you correctly, the point is not to use 76% as the font size the user sees, but just as a departure point to get a solid cross-browser base.

That is, I specify 76% on my BODY, but then P uses 102% and H1 uses 142%. (Yes, that 2% there counts for getting it right in most browsers).

I’ve heard others are using ems just as fine.

The point is, the user is not getting the 7.6px font-size he would get if I _only_ used 76%.

LintHuman says:
February 25, 11h

For font sizing I’ve been using font-size keywords for a while with reasonable success - after employing the usual hack to make sure IE5 behaves. Using percentage values on paragraphs and such allows IE to resize text at acceptable degrees: not too big, not too small.

The child and descendant selectors is the big issue, as far as I’m concerned. I want this one addressed *first*. The benefits are too great to be ignored. This and :hover support in IE would be a major step forward.

PNG support and implementation of max- and min-width are less crucial, though ought to be there in any next generation IE.

February 25, 11h

I really think browser makers should come together and agree upon a standard for hiding CSS. It should work like robots meta tags/files. Name a user agent, and you can specify whether you want only it or everything *but* it to read the code. Something like this:

/* _useragent-hide: IE 6, IE 5 */
/* _useragent-show: Mozilla, Safari */

Of course, there might be better syntax, but I’m just showing the idea. Also, I didn’t bother to type in real user-agent strings.

I doubt that such a thing would be added to the W3C recommendation. However, I’m sure there would be no complaints, given how handy it would be. Browsers will *always* have bugs, even if they are exceptionally good, so we might as well stop depending on browsers having hacks and agree on a unified way of doing things.

Dave S. says:
February 25, 11h

Chris, the more I think about it, the more I think you’re right. The major assumption in *not* having a method for hiding CSS is that all browsers will get all CSS right.

The current state of browser support is enough to dissuade anyone from this view, provided they’ve been building sufficiently complex CSS that takes full advantage of what it’s supposed to offer.

beto says:
February 25, 12h

Excellent summary of things we’ve all come to known one way or another, and best yet with workarounds supplied. Even as I’d wish to not having to do hacks, I have done the html>body trick for some time to separate IE-specific measures from “correct” measures for all other browsers.

Of those, the one that caught my attention more is the PNG support in IE, even if as gory and un-W3C as it looks. After looking at the examples though, I must admit this is something I dreamed of seeing for a long, long time. Too bad you have to trade validation to get PNG working properly in IE. We are missing on a lot of great features.

February 25, 12h

I’ll keep my mouth shut about the font-size issue, as I doubt you will budge on it.

I’ve suggested the concept of tailored CSS before - as something like:

@env[user-agent=”Googlebot.*”] {
/* Rules for Google only */

My reasoning was that you often want to tailor your CSS differently without resorting to HTTP negotiation. A standard @env rule where you could bung environmental stuff would be handy (e.g. no need for id=”www-mezzoblue-com”, just use @env[domain=…] in your user stylesheet).

February 25, 12h

Oh yes, a couple of other things: it’s a nice summary, and a good place to point people when they wonder why I hate Internet Explorer.

I’m far more likely to go with a solution that involves invalid CSS than invalid HTML for a couple of reasons. The rules for CSS error handling are well-defined, the rules for HTML error handling are merely suggestions for a basic policy. Furthermore, If there’s a problem with the CSS, it’s probable that the content is still accessible, even if that means switching off CSS in your browser. If there’s a problem with the HTML, there’s no possibility of that, unless you count “view source”.

February 25, 12h

Nice writeup, Dave. I totally agree with your statements on the CSS2 child and descendent selectors. I find myself using these more and more every day to hide things from IE. These definitely should be the last to be fixed.

dusoft says:
February 25, 12h

RE: Jim Dabell:

You can always do that with server-side scripting or even by using JavaScript, I don’t think it’s a good idea to implement such a technique in CSS.

LintHuman says:
February 26, 01h

Simon (Wheatley), It’s not width that’s the problem, but min-width and, particularly, max-width. IE does not support the latter without egregious workarounds.

I must say it seems ironic to want child and descendant selector support to be last on the list of improvements to IE, simply because we’ve come to rely on that very lack of support to hide styles from it. We should want the best for the world’s favourite browser, even if we only use it for testing ;)

LintHuman says:
February 26, 01h

Dammit, I keep saying descendant when I mean adjacent! Gah.

February 26, 01h

“IE is the only modern browser on the market that doesn’t allow you to resize pixel-value text.”
Today, no. See that: It works! Px is transformed in em by this Mazinga transformer JS.


Tomas Caspers says:
February 26, 02h

re: Chris Vincents’ suggestion of /* _useragent-hide: IE 6, IE 5 */
First of all, I guess this would mean a major overhaul of IE’s rendering engine, and MS would have to supply a patch for older IE’s out there (which wouldn’t help, since a large amount of users wouldn’t even know, and even if, they wouldn’t apply the patch - myDoom anyone?). Or MS could build this in to whatever comes with Longhorn, but then they could fix the numerous errors right away and ship a decent browser.

Jon B says:
February 26, 03h

I love causing controversy.

Browsers suck, CSS is good - don’t go breaking it up into a mish mash of bug and oversight fixes. If you want to do all this crap borwser checking malarky use something many people already love to hate - javascript for example - it can check browser types - make use of that and leave CSS clean. LOL.

February 26, 03h

> I love causing controversy.

You like people disagreeing with you?

> don’t go breaking it up into a mish mash of bug and oversight fixes.

I never suggested that. I suggested a clean way of including environmental information in selectors. As Moose pointed out, some of the functionality is already proposed as part of CSS 3.

> If you want to do all this crap borwser checking malarky use something many people already love to hate - javascript for example

If you scroll up, you’ll see I dismissed both server and client-side scripting as causing unwanted side-effects (plus they are both unreliable). If you have some magic way of making those issues go away, by all means, share them.

February 26, 03h

I’ve tried both the 76% method and the keywords method, and I have to say that I have had best luck with the keywords as long as I remember to put in the correct doctype.

I was turned on to it by after they redesigned. They have a good arguement there, although I dont believe the part about font-sizes never going below the 9px threshold as described by Eric Meyer, maybe someone else here has some insight.

My current workflow is now a mixture of keywords and px, and it seems to work really well, as long as someone doesn’t choose smallest in the font size menu :P…

February 26, 04h

> What aspect of width does IE get wrong?
> It’s not width that’s the problem, but min-width and,
> particularly, max-width.

Width *is* a problem in IE. When we give an element a width, that is how wide the element should be, regardless of how wide the content is.

Lets say we have a div with width:400px and border:1px solid #000. Now we stick a 500px wide image in the div. What happens to the extra 100px of the image?

This is controlled by the ‘overflow’ property. By default we have overflow:visible. This means that the extra 100px of the image should be seen to overlap the edge of the div. Crucially the box, as indicated by the border, should stay 400px wide.

IE gets this wrong. It stretches the box (and its border, background, etc) to contain the overlarge image, so making the width of the box 500px, thereby treating our width:400px as min-width:400px. This has knock-on effects with flowing layout around our unexpectedly wide div.

February 26, 05h

Jim, you mentioned this:

@env[canvas-width < 500px] #sidebar {
display: none;

CSS3 Media Queries, where you query the capabilities of the device support this and is already supported in Opera 7. For a quick demo, take a look at [1]

Your rule would look like this in CSS3:

@media all and (min-width: 500px) {
#sidebar { display: none; }

[1] For the time being, I’m also using this to provide Opera users with an easter egg - take a look at (How to make CSS visible for Opera 7 only)

February 26, 09h

Great write-up Dave! I think it’s pretty safe to assume that we all wish IE would update their archaic browser and help the web out. I dream of a day when I won’t have to spend hours tweaking the positioning of elements, just to have it appear “usable” in IE, when everything looked great in standards-based browsers all along…

There’s only so much illogical coding and hacking you can do before your potential is being held-back, and I think we’ve reached that point with IE.

Jon B says:
February 26, 09h

Some good stuff here, some of the comments worry me a little tho - CSS is a standard and as such it can’t be containing rules to specify the browser in which it does something. Print, screen, etc are different formats, but browsers aren’t supposed to be - browsers are merely software for displaying content from the internet and as such it is the browsers who should change to support the standards and not the standards who should change to support the browsers. Also the thing about specifying different rules for different width screens is silly too - this is not what CSS is for. We all know the browser support for standards is less than ideal - but with careful planning this isn’t really a huge problem, for many things you don’t even need hacks (I generally feel hacks should be avoided at all costs since there is no guarantee that a browser wont get an update that suddenly screws everything up coz it lets IE or whatever understand what it didn’t used to).

When producing sites for clients you can’t be giving them a site that is a potential browser time bomb, future compatibility is a must. Some people seem to be wanting to use CSS to create effects and gimmicks beyond what it is designed to do, CSS isn’t here to replace javascript or flash, don’t go suggesting that CSS should be.

Standards is about having ‘a standard’ - when you start trying to make this standard recognise different browsers and give them different content or styles you are breaking the standard - sometimes it is unavoidable, but often it is just laziness. I have nothing against CSS distinguishing between screen and print and even mobiles and pdas if the start to do that - but this is fundamentally different from differentiating between browsers - it is not the W3C’s job to sort out the inadequacies of the web browsers, the W3C set’s standards which are meant to be the future and a better one at that - if you want to moan or suggest solutions direct it towards the browser makers - one day they have to cave…

…one day…

Adam van den Hoven says:
February 26, 10h

A couple of thoughts about CSS and IE.

The PNG behaviour works fine if I want an image that is a png but I’ve never managed to figure out how to handle doing proper pngs as backgrounds? It seemed to be somewhat problematic last time I tried.

A number of suggestions have been made that we need something like IEs conditional comments for CSS. Let me remind everyone that we’ve been down this road before, granted in an adhoc fashion, with javascript and as a community we’ve rejected it. Browser sniffing is never a sustainable practice. Next month IE8.2 comes out and fixes all the CSS issues so my conditional comments that say

/* _useragent-hide: IE */

are now going to do the same thing as all the mozilla 1.x users complained about when the “This site is built if IE and you’re not using it so it wouldn’t look right anyways, go download a real browser and we’ll let you in”. Browser sniffing never works.

A better solution, in the long run, would be to capability testing. Just as all our javascript now does


I would love to be able to do something like:

@if (understandsselector(::first-child), understandsselector(:nth-child(2n+1)), understandsproperty(border-style:dashed))
is used ONLY if the contents of the () are implemented
only applies to the last @implement

It gets a little wordy but this idea is if the browser understands the argument (correctly) it returns true. It might also be useful to have it return a number, -1 if it doesn’t understant, 0 if it understands but incompletely, 1 if it does understand.

The advantage here is that we are testing for behaviour not browsers. I would also add tests for canvas size, windowsize, color depth, perhaps for input type (touch screens would have much larger button targets).

And W3C could reasonably include it in its Recs (is it too late for CSS3?).

February 26, 11h

> Print, screen, etc are different formats, but browsers aren’t supposed to be

Sure, they aren’t /supposed/ to be, but in reality, they are, and if a decent solution like this had existed from the start, people wouldn’t be scrambling around trying to find hacks.

> Also the thing about specifying different rules for different width screens is silly too - this is not what CSS is for.

I have to disagree with you here too. CSS is about suggesting a presentation. When canvas width is limited, it would often make a lot more sense to use a different layout (for instance, a two-column layout with content on the left and navigation/auxilliary content on the right vs single column with navbar on top and auxilliary content below the main content).

> CSS isn’t here to replace javascript or flash, don’t go suggesting that CSS should be.

Javascript and Flash have traditionally been used in certain areas (e.g. rollovers) simply because there wasn’t another option. Just because they got there first, it doesn’t mean that the job is not better suited for CSS.

> Standards is about having “a standard” - when you start trying to make this standard recognise different browsers and give them different content or styles you are breaking the standard

Why do you claim this? From RFC 2616:

> The User-Agent request-header field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations.

Apache, for instance, has used this in the past to avoid hanging badly-broken clients. Wouldn’t CSS rules to work around Internet Explorer’s broken implementation be working under the same principle? What’s fundamentally wrong with that approach?

> it is not the W3C’s job to sort out the inadequacies of the web browsers

It is certainly a spec. author’s job to provide for robust implementations. And the W3C authored the RFC that I quoted above. The CSS specifications in particular include a fair amount of information on what to do when a parser doesn’t understand something.

> A better solution, in the long run, would be to capability testing.

That relies on browsers being accurate about their capabilities. For instance, what about the width property? Microsoft does /something/ with it, but it’s not to spec. Microsoft could code Internet Explorer to state that it supported the width property, breaking the whole concept, or it could code it to state that it didn’t support the width property, which is unlikely at best, and would deprive authors of a valuable property.

John Prevost says:
February 26, 11h

There’s certainly going to need to be *some* type of capabilities support eventually, though. Eventually you need a way to work with CSS 3, with a fallback if you’re working with 2.1 or 2.0.

At the moment, though, with the big hitter out there almost-but-not-quite supporting 2.0, things are awkward. Theoretically, you want to live in a world where you ask “are you 2.0? Good!” and then only ask capability questions about features that are extensions to the spec. As it is, you would have to ask questions about features that are part of the spec (child selectors, etc.), which is no good.

Simon says:
February 26, 12h

OK, I’m going to stick my hand up and look stupid: What aspect of “width” does IE get wrong?

Charles says:
February 27, 11h

I really would like to have PNG support in IE, and I’m willing to do this with the filter. However, it seems that IE6/XP only honors this filter once, or it doesn’t like the other PNG’s, or I’m doing something stupid, or …

From a designer’s point of view, PNG’s can be a very nice thing to have, but it seems so hard to make IE play nice with them.

See: and set me straight.

charles, funny a with a circle, nednieuws and lastly com.

Charles Gerungan says:
February 27, 11h

Here’s my e-mail. Didn’t read that you don’t post it in the link …

February 28, 09h

I can forgive those that use 76% for IE only. Okay, I can forgive everyone, but as a user who does set a preferred font size, I get annoyed when I visit pages where the font size has been reduced from an assumed default. It’s easy to forgive those who pass 76% only to IE because I only use IE to see that my own designs don’t break too baddly in it. But hey, you could go the extra mile and pass appropriate an appropriate pt size to IE Win and IE Mac.

Phoat Spyro says:
February 29, 07h

hey guys… really good article….

I just want to say, that i’ve been using conditional comments to target IE specific hacks for a long time now, and it works perfectly and lets my CSS validate without any problems…

Also, It seems that we need a way to mass update all the browsers in the market and make them standards compliant, no matter what version the browser is. I mean, can’t someone make a plugin to change the browser’s rendering behavior, similar to the plugin used to display flash sites? I think this will solve a lot of the problems with CSS cross-browser compatibility.

February 29, 08h

One of the things I like about Opera… you can set what fonts and sizes you find most readable, and set it so the websites can’t override it.

(18 Arial, if you’re wondering. I can read 16 OK, but I like 18 better. Now, I know that’s a little larger than most people (I’d expect most people would like around 12-14 instead), but I scratch my head at the apparent common designer choice of 8 or 10. How do they read their sites without magnifying glasses? Especially since I use 1024x768, and they likely have higher resolutions? The mind boggles.)

Granted, it’s a little annoying when a layout assumes *one* specific font size, so it’s at best mildly broken, and at worst unreadable. (Why is it exactly that when I go to some sites, I see text boxes where only part of the height of the letters is visible, and the spaces between lines is all weird?) But that’s what the “turn off CSS” button is for. ;)

March 01, 07h

Among the many grievances listed, let’s not forget about lack of support for mulitple pseudo-classes, as in :visited:hover.

Rob Foxx says:
March 01, 09h

How many times did you have to point out that things “have been standards since 1997” (or “recommendations” as they were known back then) in order for us to get the point that MSIE falls short of supporting all the standards?

How many other browsers supported *all* the standards at the time IE 6 was launched? Frickin’ none of them!

You make some decent points, and give some good ideas on work-arounds, but did it occur to you that your target audience probably thinks IE 6 is a PoS anyhow?

Constant re-inforcement of *how* flawed IE is and *how* old these standards are seems a little petty - you’re preaching to the converted, I imagine.

Dave S. says:
March 01, 09h

Rob – I counted twice.

“How many other browsers supported *all* the standards at the time IE 6 was launched? Frickin’ none of them!”

That’s a little beside the point. IE6 hasn’t seen anything but security patches in two and a half years; the others are under continuous development.

“did it occur to you that your target audience probably thinks IE 6 is a PoS anyhow?”

Some do, some don’t.

victor says:
March 02, 03h

My method for showing alpha-blended PNGs validates. See it at the URL linked by my name. No scripts, just a little parse bug exploiting.

Bob Cieszkowski says:
March 03, 12h

Has anyone else noticed how the aforementioned min-width/max-width hack works fairly well in the author’s example, yet once you add a doctype into the mix IE6 chokes?

If anyone has any other workarounds (that actually work ; )for this problem, it would be greatly appreciated.


Alice Smith says:
March 04, 01h

I’m going to stick my hand up and look stupid as well: can I assume that IE treats width approximately the same as it does height?

March 20, 09h

Re: Font Size (again)

Thinking about it further, if you’re going to give IE/Win a special setting for font size, why not USE POINTS (pt)? Yes, I know points are bad for screen stylesheets because they render at different sizes on different platforms - I use a Mac and I’ve seen it; but we’re talking about a value to get over IE/Win’s font resize bug (or is this a IE problem on Mac too, I usually use Safari). If points are consistent on IE/Win then we’re set, just give pixels to standards complient browsers, figure out the point equivilent for IE/Win and use whatever method you want to give IE/Win the point value instead of pixels. It’d be neat if someone would do a good writeup about this with a chart showing pixel to points. Of course I may be forgeting some other reason for not using points in IE/Win.

Andy says:
March 21, 03h

the main problem i can see with all these new things everybody is talking about is that they wont sort out the problem. The problem is people using old software. How many people still use ie 5 or 5.5? loads. Are any of the css browser sniffing gimmicks going to make these people download mozilla/opera/safari? no. The way i see it is this… Joe Average buys a computer, they use it till it breakes, they get a new one.
Joe Webdesigner buys a computer hates IE, changes browser default, regularly updates, the end.
In other words we’re stuck with ie 5/5.5 for the next year or two, IE6 for about the next 4 years (about as long as it takes for the average user to upgrade, i think).

As for missing css features in IE, its got to be… position: fixed; how much easier would it be to have a footer then?!?!?! 3 column layouts would be easy as PIE (get it?) and if the right: 3em would work as well? life would be just dandy. I think that would revolutionise web layout design.

Ludwig Rudertaller says:
March 24, 07h

in reply to Chris Vincent

Hi Chris,

maybe i misunderstand you, but you want a “select” ala
if useragent == ie use this CSS

this is possible for IE



JDenny says:
May 12, 08h

I’ve been using Conditional Comments for a some time and like as mentioned in some previous comments, they are the best way to provide ONLY IE with CSS and JavaScript and anything.

Less known, is that you can also use conditional comments to provide code to EVERYTHING BUT IE.

I also use expression() syntax in CSS properties to put ONLY IE values inside CSS rules. Also someone told me about the underscore trick: certain properties preceded by _ will work for IE, for example _width: 30em; will be ignored by most browsers but obeyed in IE.

Using behavior: url(‘….’); to add scripting is a great idea too, but don’t forget it is not just IE that will support it in the future - it’s a working draft or something like that for CSS3.
You can provide link to behaviour files to IE only using one of the tricks I mentioned above.

Enough tricks, back to the issues at hand!

OK it really sucks that IE is not being developed fast enough, but for the sake of the future, lets do everything we can to push MS to fall in line with the newer browser standards.

IE do some great advanced stuff with JScript, CSS typography, scroll-bar colouring and behaviours that are far ahead of the other (newer) browsers. So why can’t they focus some effort onto meeting the standards (accurately) in consistency with the other browsers and fixing the many bugs?
I don’t know but if you’re wondering why they should, it’s because the advanced stuff is pretty useless if it only works on one browser, we can’t use it fully, just like we can’t use advanced CSS fully only IE is the one with support rather than without. Giving us the innovative advanced stuff is great, but we’de rather IE didn’t make our lives so dificult working around it’s problems - then we might actually have time to investigate the snazzy advanced IE features!

So aside from the comprehensive lists and guides to avoiding IE bugs and short-comings, here’s my priorities list of support they don’t have…

1) Generated content! Including the ::before and ::after which will allow us to use CSS2 border tricks suck as those shown on A List Apart without adding extra HTML - we can get the CSS to generate the extra containing blocks instead! Now please support it so we can use it.

2) Rules! Advanced selectors are very powerful. I want to use the child/parent, sibling, adjacent, :hover :focus and even the [@attribute=expression] syntax so that I can target elements more specifically and accurately. And that includes combining them (like a[@target]:visited:hover and more).

3) Rendering! The ‘position is everything’ site mentioned in another comment is a good list of rendering/positioning bugs, but the most important problem for me is the box-model is not correct two respects: one: content edge vs border edge, two: overflow: visible; effecting block size and borders (and hence layout flow) rather than just content-box size. Also white-space-characters often effect rendering/poitioning when it shouldn’t. And who can forget lack of position: fixed; and incorrect background-position: fixed;! Fix all these please! Most important is the box model including overflow problems.

4) Support for min- / max- dimensions and symbiotic left AND right combinations will allow us to create layouts that are more flexible and fluid without breaking so easily or compromising usability at extreme resolutions.

5) Strict? Please IE, when in strict mode have a tighter conformance to recommended W3C standards. In short, this requires you to be more accurate and comprehensive in your W3C standards implementation!

6) Definition!
Don’t make us leave things to chance by setting a bug to patch a bug. Fighting fire with fire is never a good idea. Let us be explicit - let us chose strict or quirks mode with a meta tag rather than hacks!
(Or is this already possible and I haven’t heard?)

7) z-index! Why should a plug-in stay above everything else? Same for UI widgets like combo-boxes? If we cover something up with a layer in front of it, the chances are it was intentional, we know what we’re doing you know!! And I’m not sure about the W3C specs but I’ve currently got trouble trying to put my absolute positioned elements behind others even thought I try to do it explicitly with z-indexes.

8) This one’s not really CSS but…
Better Object Orientation in the DOM would be nice, specifically, I’d like to add to the prototypes of default HTML elements. It works in fully DOM compliant browsers I think, - in Mozilla (FireBird) I can add setters, getters, functions, attributes (including default values) and maybe events too. I’ve been trying to make IMG elements take a hover_src attribute and automatically do mouse-over effects with it, but I got stuck trying to do it in IE, and had to get a script to run on document load to dynamically add the functionality to each element!
(Yes I know I could use a behaviour or expression() for this particular example, but the functionality I described is in my opinion MISSING from IE).

CSS future…
The environment rules are a great idea and they ARE part of what CSS is for - presentation. The @media rules were a great start to providing different CSS to different presentation mediums, and taking user-agents, canvas dimensions and colour depth into account is a highly useful extension of @media.

However, even more useful than using environmental variables to branch code, would be if we could actually use the variables in values! You can do this in IE using expression() syntax, which provides all variables you can access using JavaScript (or Microsoft JScript).

Wouldn’t it be nice to have values we can use in CSS that represent the user’s screen resolution, DPI, and canvas width and height? As I said you could implement this in IE using expressions. This would be in addition to the @env ideas (or @media extensions) which would still be needed to branch code.

You could take it further with user preferences that we can access…

What if there was a standard way to store you preferences for presentation, that CSS could check up on and use as values or to branch the code?
Imagine Joe Bloggs is colour blind and has low light sensitivity. He recorded it in his profile that we can access through CSS. Now we know, we can provide a colour scheme with better contrast and clearer text (etc) which we wouldn’t normally do for ‘normal vision’ users because it would look too bright and possibly ugly.
Just a thought really but wouldn’t it be useful if we didn’t have to guess any more?

We can already use system colours as values in CSS, but only for colours. So you could use them to get a colour scheme the user can use, but it’s not ideal and it’s not enough.

Those of us that set a preferred text-size can get annoyed at sites that change it, but most people don’t set a preferred size and are grateful that the page has been set up with pleasingly sized text. Imagine if you could do a simple check in your CSS to see if the user has set a preferred size and then either honour their choice, AND provide a size for users that haven’t chosen one already!

This user profile idea is analogous to ICM Colour Profiles that help user-agents adapt to accurately reproduce colours on varying pieces of hardware.

I was also going to suggest min- / max- font-size, but I’m sure it wouldn’t be long before that was abused to fix font size to exact pixels!

When is CSS going to provide block-align? and content-align?
I want to specify a block should be centred in the page, this is very common and very easy with layouts! We need block-align!
I also want to specify what happens to content alignment when the user changes text-size, I have buttons that are a fixed block size with a background image, but the button caption is made of text in order to allow users to resize it. Unfortunately it gets hidden (in Mozilla FireFox) because when u resize the text it overflows toward the bottom-right of the screen. IE is better in this respect because the text resizes and stays central within its containing block, meaning the text can grow more without overflowing. We need content-align (or text-align-vertical).

We also need more control over what parts of the layout should be flexible and stretchable. Using percent% units is not good enough, min-/max- might do a good job (but I haven’t tried that as IE doesn’t support it), and symbiotic left and right positions doesn’t work with position:static; elements.

Sorry for such a long comment, but I hope you all damn well read all of it! :)

Zoe says:
July 20, 06h

Hmm, sorry, but the min-width trick mentioned in the article really doesn’t emulate min-width. Standard-compliant browsers make the div 100% unless 100% is less than 700px, at which point they make the div 700px exactly. But in IE, you get a div that is always 700 pixels, except if non-breaking content larger than 700px is placed in it. Even so, the div does not resize with the browser window as it should. It is never 100%. So, this trick is really more of an emulation of display: table-cell. It does not emulate min-width.

September 20, 12h

A technique to create simple simple PNG alpha transparency in IE while allowing for higher quality transparency in other browsers with no hacks whatsoever:

eaglerayoflight says:
September 23, 05h

Totally classic - had to switch to IE from Firefox to get this comment posting mechanism to work. Firefox is a great browser but I guess it still has a few rough edges.

Conditional comments have also proven to be a great tool for me — they are great for creating IE specific stylesheets, which from what I have seen here seem to be an absolute neccessity.