Charting your Safari

June 30, 2003

There was a lot of good news last week out of WWDC. My personal favorite was the new version of Mathematica, but that’s just me. For many people, it would have been the much rumored G5 machines. For Web developers and authors, I’m guessing the 1.0 release of Safari was the biggest news, and good news at that. For me, it’s good news and bad news. It’s great that this excellent, highly standards-compliant browser is out of beta, but the bad news is that I now have to update the MacEdition Guide to CSS2 Support in Mac-only browsers, and then transfer that information into the Abridged Guide that covers more browsers, but in less depth. That’s actually a fair bit of work, and I have a pretty demanding day job.

Still, the other good news is that Apple has published a proper support chart for Safari’s CSS capabilities. It describes whether or not a particular property is supported, and notes important exceptions to that support. For example, min-width works only on non-positioned elements that aren’t “replaced” elements like images.

I’ll still be verifying all of this myself but having the publisher’s statement about support is an extremely helpful starting point. Apple’s support chart follows the (CSS1-only) support info from the Mozilla team, the statement by Opera about its version 7 browser, and Microsoft’s statement on IE6.

These are generally basic charts indicating whether a property is supported or not. But sometimes it’s not that simple. Bugs arise in special edge cases, particular combinations of properties or elements together – tricky things that are hard to test for.

At this point, as we survey the six rendering engines (IE6, IE5/Mac, MSN/OSX, Gecko, KHTML and Opera) with good to excellent CSS support and the dozen or so browser products incorporating those engines, it’s worth taking a step back. Just what kind of standards support information do web developers need? I know that most of the reactions I’ve been sent about MacEdition’s Guides are just requests for more browers (no time, sorry) or a printable version (with a print stylesheet and PDF, maybe, and perhaps an interesting project for a generous minded reader). But maybe the content could be improved, too.

The main critique about the actual content of the charts has been from Safari developer Dave Hyatt. He makes the legitimate point that just checking one or two examples of a property isn’t enough to really assess support for a property. Sometimes the simple cases will work, but the more complex cases won’t. Or it will be a case of a property working for one class of elements but not another – divs but not form elements, images but not text. Or maybe it’s an issue about combinations of properties or elements, like the Netscape 4 crasher bug that occurs if you use three particular properties at once, even though any two of them work fine together.

I plead guilty in the case of Safari. I didn’t test it as heavily or in as much depth as some of the more problematic browsers like iCab or pre-WebCore OmniWeb. And given my comments eighteen months ago expressing almost identical sentiments, I really should have known better. The simple fact is that when time is at a premium, and things are working well so far, you assume that you don’t need to test too deeply. It’s when things aren’t working that you get suspicious and dig further. It was simply a case of the squeaky wheel getting the grease. And anyway, Mark Pilgrim has a time-zone advantage over Aussies like me, and can find all those bugs while I’m still asleep in the hours after a new version’s release. So I felt I could add only limited value to testing of Safari. In contrast, there had been a complete vacuum of information on iCab and OmniWeb that I tried to make up for with the original MacEdition CSS guide.

Dave believes that the solution to inadequate detail in support charts like MacEdition’s is better, more thorough test suites, and puts the onus for writing them squarely on the W3C and browser developers. I concur that good test suites need to come from the authors of the specs, who know how it should work, far more intimately than any outsider. I simply couldn’t have provided the charts I’ve produced without Eric Meyer’s Draft CSS2 Test Suite, or the W3C’s test suites for CSS1 and CSS3 selectors. But I think the process of finding bugs and support gaps is never going to be completely covered by any test suite. There are too many properties, which can apply to too many elements. When you start considering combination of properties or nested elements, things just exponentiate. Frankly, there’s no substitute for using a browser day-to-day and following up what looks wrong. There’s nothing like testing your site in a range of browsers, and documenting the bugs one encounters, instead of just quickly working around them and hoping for the best as you scrape in under your deadline.

If you want an example of why this is important, here it is. As is clear from MacEdition’s charts on CSS2 and CSS3 selector support, MSN for OS X sails through the test suites. This should come as no surprise: the lead developer of its Tasman rendering engine, Tantek Çelik, is a co-author of some of the specifications and test suites. And I know from the public statements of MS employees, including Tantek, that they love test suites and support charts and want to do their best to measure up to them.

But when you dig deeper, and try to use that browser day to day, weird stuff happens. My next project as CB is to dig deeper into the strangeness I’ve encountered, but for now, here’s a freak-show gallery from MSN. We have the white-space bug I’ve already encountered but there are also many others. I’ve been sending these to Microsoft, of course, and I suspect I’ll find more over time, at least until my free period starts running out and they start charging my credit card.

You’ll never catch all the bugs with a pre-specified test suite. You have to keep an eye out for glitches and narrow them down. As Web authors get more ambitious in their use of CSS, we’ll have more examples to work from. But to be effective at working out what’s going wrong, you need to be systematic, you need to know the difference between the browser’s problems and your own, and you need to be able to describe what you’re seeing in a sensible, concise way. The contents of my mailbox shows that not everyone is capable of all three things. That’s ok, but remember, you get out what you put 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