Codebitch : Click to return to MacEdition homepage
 

CodeBitch Extra: CodeBitch is on Safari

January 14, 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!

Well, I got it half right in my last column. Apple really was bringing out a new browser called Safari – “bring the safari to the jaguar,” as I hinted on the day before the Expo keynote; but I was bamboozled by the user-agent string, and thought it would be based on the Gecko rendering engine. It’s not. Instead, Apple have used the KHTML engine seen in Konqueror. I was very surprised to see this – KHTML has barely been on the radar of web developers unless they’re catering to an audience with a big slice of Linux users. I don’t think I’ve ever seen a screenshot of MacEdition in Konqueror, though I’m told it looks fine, and it looks fine in Safari, too.

Naturally, Web developers were a little taken aback. Most of us would rather have a small number of engines to support, and Mozilla’s is well-understood and has few remaining glitches. Many people see it as the gold standard for standards support, with good reason. Though I don’t fall into the same camp as Mr. Vincent “I only want to support one web browser” Flanders, the complexity of working around the bugs in the array of Mac browsers is becoming quite daunting.

Everyone’s been hammering on Safari in the days since its release, with lots of people finding the odd CSS bug here and there, and some people building whole lists of them. (As an aside, let me tell you that if you want to be taken seriously as a finder of CSS bugs, follow Mark’s approach. Build minimal test cases and supply screenshots. I’ve received many “bug” reports and seen even more complaints about “buggy” browsers from people who manifestly have no idea.)

As with other Mac-only browsers, you’ll find the most comprehensive guide to CSS support right here at MacEdition. Because Safari is based on KHTML, much of the documentation for Konqueror can be used as a guide. But Apple’s improvements to the rendering core mean that support charts for Konqueror can’t be taken as gospel for Safari – not that we should believe everything browser-makers claim about their products anyway. As best I can, I’ve tried to verify all claims myself using standard test pages. Of course, if anyone can provide test cases for either support of properties, or bugs in that support, do let me know.

There are some disappointments in the initial public beta. These include the lack of support for XML, the title attribute on links and images, and the <object type="text/html"> method of embedding pages in pages – on which the W3C CSS1 Test Suite relies. What’s heartening, though, is the speed at which the Safari team are responding to these reports and (reportedly) fixing them in internal builds. OmniWeb has had the same problem withobject for ages, and it still hasn’t been fixed. Surely the Omni engineers notice the problem when they go through the W3C test suite?

I’m not going to expound upon Safari’s interface, or the speed, or anything else outside my usual web standards purview. My view is this: the CSS support in this browser is pretty darn good, especially for a beta. The glitches and bugs that exist seem to be being fixed: click that spider and holler at Apple – that’s what it’s there for. The Safari team are smart and nimble and understand standards, and between them and the KHTML team, they’ve done a better job at first go than the Windows IE team have managed. (Go look at Dave Hyatt’s weblog in IE6 and check out the background repainting problem Windows IE6 has with negative margins – and then tell me why some people are bitching and moaning about a beta browser on the minority platform!) Indeed, many of the “complaints” about dubious standards support are based on the “evidence” of malformed markup and shoddy stylesheets, or on no evidence at all. People need to put up (and provide test cases) or shut up.

The promise of the browser and the commitment of the development team to standards both suggest to me that one of the current concerns amongst web authors – finding a CSS hiding method – is actually very low priority. I would be happier if there were no ways to hide CSS from Safari than that it had hiding methods that overlapped those for browsers like OmniWeb, iCab or Netscape 4. Nobody seems to mind that there’s no way to hide CSS from Mozilla-based browsers, after all. If the remaining gaps in Safari’s CSS support – overflow, max-height and the link, content and a few others – then who cares if there’s no way to hide CSS from it? There will be little need to do so. Adding unrecognized proprietary hacks and media types strikes me as foolish – the whole point of web standards is avoiding those kinds of hacks. They’re a desperation measure, something we need for the bad browsers, not something we should demand of the makers of largely good browsers. Anyway, where were all those advocates of hiding methods when I was struggling along trying to identify bugs in OmniWeb and iCab? At least Omni can see the writing on the wall, and look likely to replace their own shoddy rendering engine with Apple-enhanced WebCore.

I’m optimistic about Safari. In coming weeks, I’ll let you know how many MacEdition readers have switched to it. I’ll also be updating the MacEdition guide regularly as new information comes 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!