We’re all banking on a better trip

Now Up-to-Date & Contact: The #1 calendar and contact manager for the Mac – now Cross Platform! Click here for a 30-day free trial.

March 24, 2003

ESPN was the kicker. Sure, they’re spattering class attributes around like a Grand Prix winner does champagne. They have spacer DIVs. They have validation errors because of the MSN crud and advertising they’re obliged to carry. It’s not the way I’d do it, but they’re using standards-based design and CSS layout, and they’re reaping the benefits. They get lower page weight, easier site maintenance, and confidence that it will work in standards-compliant browsers like Opera and Safari, even if they don’t bother to test the site in those browsers.

If Wired and Lycos weren’t enough, here’s an utterly mainstream, non-geeky site that’s marched forthrightly into the 21st century. Gone are the days when I could say that the only standards-compliant sites were, well, sites largely about web design and standards. It’s no longer even completely true to say that it’s only the independents and amateurs whose sites validate. Sure, the independents and amateurs are well ahead of the so-called professionals, but more and more of the big boys validate now, too.

Of course, ESPN going standards-compliant also means ESPN breaking in non-compliant browsers like OmniWeb and iCab. OmniWeb goes to their browser upgrade page, while iCab gets through to the front page and chokes on it. Either way, users of these browsers are getting yet another message that their browsers aren’t up to scratch. Hopefully the makers of these browsers understand the urgency of the message, and there’s considerable evidence to suggest that they do. With the release of iCab 2.9 in February, its makers included a readme file promising much better CSS support in Version 3. We have since learned that Version 3.0, whenever it comes out, is at the very least slated to include support for CSS positioning. Similarly, the Omni Group has been promising better standards support in OmniWeb since the early betas of version 4.0. There were improvements in 4.1, but not in 4.2, and its CSS support can still only be described as broken. High expectations for 5.0 have been set since 4.1 was released. They seem more likely to be fulfilled if the Omni Group goes through with their mooted plan to adopt KHTML as their rendering engine – the same engine driving the excellent standards compliance of Safari and Konqueror. Higher likelihood doesn’t equal certainty, however. Even if the Omni Group does end up adopting KHTML (or if they adopt Opera – that would solve two problems), there’s no guarantee that OmniWeb would render the same as Safari. I’m not sure why, but OmniWeb uses the SpiderMonkey JavaScript engine also found in Mozilla – but doesn’t manage anywhere near the JavaScript or Document Object Model functionality of Mozilla and its derivatives, Chimera, Netscape and Phoenix. Apple’s recent tests of OS X browsers’ JavaScript capabilities – no doubt motivated by a desire to boost Safari – shows OmniWeb lagging badly behind the rest. If they can stuff up SpiderMonkey, what’s to stop them stuffing up their integration of KHTML? These kinds of modules have to connect to other parts of the browsers core – in particular the DOM implementation needs to connect to the rendering engine. Two great modules could end up connecting together very badly. I’m not saying that’s what will happen but the experience of other licenced code inside OmniWeb makes me very skeptical.

iCab is another situation. Its excellent support for the nether reaches of HTML 4.0 suggests that its author is well capable of reading a W3C standard with understanding. So why does iCab incorporate so many basic mistakes in the CSS implementation, from miscalculating percentage widths, to not inheriting font styles into tables, to adding defined margins to the defaults instead of replacing them? Support for basic layout techniques like CSS1 floats and CSS2 positioning are the minimum we should expect from a 2003-vintage browser. There are elements of CSS2 that the W3C gave up on for CSS2.1, but that’s beside the point for iCab and OmniWeb. OmniWeb messes up the box model and gets borders wrong, while iCab has problems with margins – all basic properties in the 1996-era CSS Level 1 standard. In 2003, there’s just no excuse for that.

I know a lot of you will think I’m being too hard on the little guys, that I should cut them some slack. After all, we all know that iCab is basically one guy, and OmniWeb is basically three guys with other projects to work on as well. I guess I could respond with something about getting out of the kitchen if you can’t stand the heat. Instead, my response is that small teams are an excuse for doing less, but they’re not an excuse for getting it wrong – and for even these simple, basic, CSS1 styles, iCab and OmniWeb get things utterly wrong, Netscape-4-like wrong, goodness-me-what-were-they-thinking wrong.

No, the reason for the problems in these browsers isn’t the number of people working on them. It’s the kind of people not working on them. All of the major, standards-compliant browsers have at least one standards maven on their teams. Tantek Çelik works for Microsoft, and was one of the editors of CSS 2.1. Eric Meyer was an invited expert to the W3C Working Group that developed CSS2; now he’s a Netscape Standards Evangelist. The Mozilla team also includes standards experts as Ian Hickson (an editor of CSS2.1) and David Le Baron, another W3C invited expert. David Hyatt is the standards compliance leader for Apple’s Safari team, was formerly on the Mozilla team, and has also been involved in the development of W3C standards. And of course, Håkon Lie was one of the original developers of CSS, and is now Chief Technology Officer at Opera. Omni and iCab don’t have anyone like that. I don’t see any Omni Group staff taking active involvement in W3C activities the way these previously mentioned folks do. Implementing standards (as opposed to just using them) is hard, and the Omni Group aren’t getting involved with the people that could help them do it right.

It’s the same with bug-squashing. When Safari came out, many people started bug-hunting and helping Apple improve the product. Nobody bothers with OmniWeb and iCab, it seems. The closest they get is me – even Apple used MacEdition’s CSS compatibility chart in their Internet resources.

Frankly, I don’t have time to be the Eric Meyer for Omni or iCab, nor do I really have the expertise. Someone needs to help them if they can’t help themselves. Are there any takers?

— 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