Everybody else is doing it, so why can’t IE?
May 5, 2003
Feedback Farm
Have something to say about this article? Let us know below and your post might be the Post of the Month! Please read our Official Rules and Sponsor List.
Forums
Want to dig even deeper? Post to the new MacEdition Forums!
In the days before sixth-generation browsers like Mozilla, Safari and Opera were around, Web designers used to fantasise about only having to support one browser. Web standards just weren’t working back then, and heavy use of CSS was considered just too risky. Nowadays, pretty much everyone has access to a recent, standards-compliant browser, whether it’s one of the Netscape-Mozilla-Camino-Phoenix crowd; a KHTML-based browser like Safari; Konqueror; the new version of OmniWeb; or the latest versions of Opera and Internet Explorer. The only users of standard desktop browsers with any excuse for using something with poor standards support are those whose elderly machines or ultra-conservative IT departments require that they use Netscape 4.
But sometimes you are given a project that requires support of only one browser. An intranet project, say. For one of those organisations running one version of one browser on one platform. Of course, even in a one-browser world, designers should still stick to the specs. You never know what proprietary approach is going to break in a later version of that one browser. But can we push the boundaries and explore the little-known portions of the spec in those circumstances?
Alas, the answer is no.
The answer is no because, of course, a one-browser corporate intranet project means Internet Explorer 6 for Windows. And I’m fast learning that IE 6 is perhaps the least CSS-capable of the family of browsers that people usually call standards-compliant.
To the standards-faithful department
Don’t get me wrong. The bugs that Windows IE has – the things
it tries to do but gets wrong – are not that numerous. (And thanks
to Big
John, some of them have really cool names.) Some of them can be darned
hard to isolate, even after some of the finest minds in Web design have
had a go at the problem. Others are more obvious. I mean, come on –
CSS Level 1 has been around since 1996, and Windows IE still doesn’t
do background-attachment:
fixed
right for any element other than body
.
What really peeves me is the lack of support for the cool stuff, the stuff in CSS2 that can really lighten your page’s weight and add functionality unimaginable in the tag-soup paradigm.
The intranet project on which I’ve recently sub-sub-contracted indicated a need for a toolbar of frequently used links at the top of the screen. It would be cool to ensure that it was always at the top, even on a long page. But you couldn’t use a frame because you didn’t know in advance how tall it would be (leave aside the extra maintenance issues for now). The people who are going to be using this system have wildly different text-size settings; some of them have vision impairments, or perhaps they just find that small text is too hard to read on their big, high-resolution screens. If you sized the frame too small, up comes an ugly scrollbar, slowing down the system’s users even more than if it wasn’t a frame at all.
A div
styled as position:fixed
would be just
perfect for the purpose. Long-time readers might recall some of my earlier
experiments with this CSS2 property in a demonstration of the ease of
re-design with CSS-oriented
layouts. The property works in IE5/Mac (with link
glitches), Opera, Gecko family browsers (Mozilla, Netscape, Camino,
Phoenix) and KHTML family browsers (Safari, Konqueror, OmniWeb 4.5). But
it doesn’t work in IE6 for Windows.
So scratch that idea and start again.
Here’s the most common browser on the Web today, holding back companies from doing something would work well for them, something that has been part of a published W3C standard since 1998, and which its Mac OS counterpart has been doing right (modulo those problems with links) for three years.
Of course, that didn’t stop the W3C from using
position:fixed
in its CSS main page, but that’s an
act of chutzpah that I can’t recommend for a corporate intranet using
only IE6.
Doors and Windows
Sometimes it seems that certain parts of CSS2 will never be widely used because everyone’s so afraid of things breaking apart in whichever laggard browser they must support. CSS2 selectors are a case in point. The really obvious gaps in IE6’s CSS2 support are in the selectors. We’ve gotten used to using its blindness about selectors to create quick hacks around its other quirks. Who amongst us hasn’t done something like this?
#myDiv {width:100%;}
html>body #myDiv {width:auto;}
There are times when I would really, really like support of the direct-child selector
(>
), but again, Windows IE lets us down.
Lack of support for the direct-child selector means your stylesheets are
more complex and harder to maintain. The intranet project I mentioned
earlier used a lot of little callout blocks next to particular headings on
long pages. This is an obvious use of
floats. We assigned extra padding-right
to the main
text’s headings, paragraphs and lists to create the illusion of a column
for the floats to sit in, rather than running the text right around the
floats. But of course that padding also cascaded to the paragraphs and
lists in those floated callout boxes, which we then had to override
separately. That’s a whole rule block that would not have been necessary if
IE6 supported the direct-child selector and allowed us to assign the styles
only to the lists and paragraphs directly inside the containing
div
instead of inheriting to all such elements in the
div
. Lack of support of this selector added a significant
amount of time to my recent project’s prototyping time.
It’s the same with the sibling
selector (+
). How many times have we defined a class
which must then go into the markup, instead of using this useful little
selector to enforce things like the spacing between a list and a paragraph
being different from that between two paragraphs? Or attribute
selectors, another gift that keeps on giving and reducing the need for
400 different class definitions?
No need to argue
I’m not the only one to notice just how much IE6 is dragging the chain. In his admittedly simplified ranking of CSS2 capabilities, Peter-Paul Koch showed that all the other standards-compliant browsers do better than IE6. For a somewhat more apoplectic take on the issue, standards maven and cat lover Ian Hickson has linked a bunch of test pages that IE6 fails. Sure, some of the other browsers fail some of them and have other support gaps, but they do better than Windows IE.
The basic issue is that it’s easy to do both basic and innovative design work in CSS, and know that it will work in Gecko, KHTML and Opera browsers, and probably also Mac IE, with no tweaking. Getting it to work in Netscape 4 was always the big bugbear, but it turns out that getting it to work in Windows IE is also difficult. No wonder there are still people out there who think that font tags and quintuply nested tables are a better alternative. (And no, I’m not going to link to the latest flamefest involving Dave Winer on the subject. There will plenty more of those.)
Wake up and smell the coffee
What to do? There are rumors of a new version of IE for Windows. However, it just doesn’t seem as imminent as the new IE for Mac OS X, which I’ve already seen in MacEdition’s logs. The new IE for Mac will have the same rendering engine as in the MSN Explorer browser for OS X, which has already been announced, so I infer that the regular IE/Mac isn’t too far away. As for the next version of IE/Windows - who knows? It could be years away yet.
Microsoft needs to understand that browser development doesn’t stop here,
even if the Browser
Upgrade Campaign has. It still has work to do. And one of the best
ways for it to learn this is through the time-honored tradition of mockery.
Now is the time for the Mac IE team, which is largely getting it right, to
start sticking it to its Windows IE counterpart. Use CSS2 selectors in
your intranet pages. Send the Windows team little emails saying, “Our
browser supports the :lang
pseudo-class, how about yours?”
Design beautiful sites that work fine in Windows IE, but look subtly
different and better still in more capable browsers.
And on the last point, the rest of us can definitely join in.