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.

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 :hoverdoes 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.

Summary

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

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:

I’ve been using some javascript hacks for both PNG and min/max-width support in IE. The width script can be found at http://www.doxdesk.com/software/js/minmax.html 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.

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.

The key to get a validating website which is relatively cruft-free is to add conditional comments (http://msdn.microsoft.com/workshop/author/dhtml/overview/ccomment_ovw.asp). 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.

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.

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:http://www.mozilla.org/ns/M1.6 screen, UA:http://www.opera.com/ns/O7.11/linux alternative all” This seems to be the most flexible to me.

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.

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:

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.

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.

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

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

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.

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 ;)

“IE is the only modern browser on the market that doesnâ€™t allow you to resize pixel-value text.”
Today, no. See that: http://www.lucamascaro.info/trasformer/. It works! Px is transformed in em by this Mazinga transformer JS.

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.

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.

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

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 www.alisapart.com 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…

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.

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.

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…

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

if(document.getElementById)

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
correctly
*/
}
@fallback{
/*
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?).

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

Behave!
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…
EUREKA!
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! :)

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.