Archives filed under "standards"

So true.

It’s not unlike the situation with bugs: you solve one, and 14 new ones pop up.

If you’re a web developer, you’re going to be interested in the fact that Microsoft Internet Explorer 8 has been released.

There’s a lot of good news: it’s passed the Acid2 test & supports CSS tables, making it the last major browser to achieve both of these. Apparently it’s also more secure than previous versions, although that has yet to be fully tested in the real world. Finally, it’s also faster than previous IE versions, although according to Computerworld, IE8 is still the slowest browser based upon SunSpider benchmarks. In my (very limited) experience, IE8 is significantly faster than previous versions—not dramatically so against Safari or Firefox, however—but more importantly I’m grateful that it hasn’t munged up any of my layouts!

What a difference a few years make: when IE7 came out, it’s only real competition came from Firefox (with Opera as well, of course). It’s now a very full field, with Safari & Chrome freely distributed as well. It’s really great to see such strong competition, and it has to be said that the IE team seem to have done a good job on the browser.

It remains to be seen what the new release will mean for IE’s declining market share; I can’t speak to that. For developers, IE6 was pretty odious & IE7 a bastard step-child of a browser, as it only made half-steps towards standards compliance. IE8 has removed support for HasLayout, the code that trips up most developers, including me.

But… the insta-reviews aren’t positive, and although they’re concentrating mostly upon installation problems, the centre of my concern lies in advanced standards support. There’s still a lot of room for improvement from a developer’s point of view. Whilst the other major browsers have passed the Acid3 test, IE8 still fails, and pretty miserably.

Just as important is the lack of CSS3 support. One might argue that CSS3 isn’t a full recommendation yet, but its development was modularised so browser vendors could start implementing portions as they were completed. And on this score, Safari & Firefox roundly beat IE8. I know I’d love to have multi-column & RGBa support across the board. Yet even if IE8 did support these, it’d be years before we could use them with confidence, that is until older IE versions finally dropped off the face of the earth The fact that the IE team haven’t supported them yet means the day is that much farther away.

Maintaining Older Browsers for Testing

If you’re like me, you’ll have multiple slices of Windows so you can test sites against IE versions. To not get tripped up & accidentally overwrite an IE6 or 7 install because of an automatic update, I’d suggest you install the IE8 blocker toolkit.

In the past couple of months, two authors whom I admire have renewed interest in Dean Edwards’ confusingly-named IE7 script—a Javascript hack that makes Internet Explorer version 6 behave more like a standards-conscious browser.

The very title of Eric Meyer’s article—“Javascript will save us all”—suggest that we’re about to enter a golden age in support for the seven-year-old browser. And Jeremy Keith has recently advised people how to gauge when to use the IE7 script.

Well, I don’t know about you, but to me, this is more than music to my ears, it’s the equivalent of Bach being played on a glass harmonica right next to a chocolate fountain. But years of struggling with IE6 have hardened my defences. Since using Meyer’s CSS zero reset I’ve had great results with IE6—but only from the beginning of a site design I hasten to add. As I’ve written earlier the reset does little to fix a pre-existing design.

Dean’s script has popped up now & again over the years to tempt me again & again with its promises. But it’s nowhere near as well-known as you’d expect for something that gets such high praise from some very astute authors. Why is that?

Well, it might be because it doesn’t really do what you hope. It’s certainly nothing like a magic bullet. In fact, I’d recommend that you stay away from it. Why? Because you’ll have to go through the hard work of declaring a separate stylesheet for IE6 anyway: adding another script to the mix just adds more to the confusion of figuring out why something doesn’t work.

Both Edwards’ script and Keith’s recent article popped into my head because recently we’ve been working on the site of one of our favourite clients. In the course of making the site more amenable to search engine optimisation, it became clear that we should revisit the CSS of this, the last site we developed without the CSS reset.

The DD site as planned, in a standards-compliant browser

The DD site, as seen in IE6, based upon particularised CSS tweaks

The DD site, as seen in IE6 with Dean Edwards’ IE7 script

Now, it might seem like I’m cheating in the above examples: I removed the painstakingly-tweaked IE6 CSS when I introduced Edwards’s script. But I’m not. If I were to follow Meyer’s & Keith’s advice & used the IE7 script as a basis for my IE6-oriented work, I’d have a hell of a lot more tweaking to do, plus I’d have to cope with the rigmarole involved in dealing with someone else’s script.

So, take some advice: if something looks like it’ll magically solve all the problems that have consumed years of painful work, don’t bet your reputation, or your schedule on it.