Codebitch : Click to return to MacEdition homepage
 

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.

— CodeBitch (codebitch@macedition.com) is the grumpy cow who does the HTML production for MacEdition. Read other articles by CodeBitch

E-mail this story to a friend

Talkback on this story!