| Thursday, January 9, 2003 |
14:04 - Pilgrim's Progress
|
(top)  |
Safari may have a long way to go before it's ready for prime-time, but it's already overcoming its initial limitations by leaps and bounds-- it's only been out for two days, and apparently most of the biggest rendering/CSS issues have already been addressed in the internal builds.
This is largely thanks to the unaccustomed transparency with which Apple has flung itself into the Safari project. (And I'm not talking about the Quartz kind.) Via LGF comes Dave Hyatt's blog-- he's a Safari developer posting the details of the project's progress on his MozillaZine site. He's apparently already found and fixed the primary reason why Safari hasn't been able to run the standard CSS1 test suite; he's also providing an illuminating look into Safari's behavior choices, which seem (as with so many things Apple) to all have some kind of sane reasoning behind them:
A number of people have commented on Safari's UA string, which is as follows:
Netscape 5.0 Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/48 (like Gecko) Safari/48
The portion of the UA string that seems to be stirring up controversy is the portion that says (like Gecko). The reason it is there is that in order to work with real-world DHTML sites you have essentially two options: you can claim to be MSIE or you can claim to be Gecko. We found that any other choice that we tried led to a significant portion of DHTML malfunctioning. You would not believe (well, maybe you would) how much DHTML exists out there that works only with MSIE or Gecko, and that uses proprietary extensions of each to accomplish the DHTML effects.
Had we released a browser with a UA string that did not superficially match either MSIE or Gecko, users would have downloaded Safari and experienced many malfunctioning Web sites. If anyone thinks that would have been a good idea, please step forward in your blog and explain why. I'm willing to listen.
Our solution was a compromise. We produced a user agent string that is different from Gecko's and easily distinguishable if you choose to sniff for it, but that at this time will pass most UA checks that sniff for Gecko. It may be that enough sites will start sniffing directly for our string that we can drop the "(like Gecko)" from our user agent string, but I'm not optimistic.
We chose to be more like Gecko than like MSIE because we wanted to be lumped into the standards compliant category, because fundamentally we are committed to supporting DOM 1&2, CSS1&2, and enough proprietary MSIE extensions and Gecko extensions (innerHTML, createContextualFragment, offsetWidth/Height, etc.) that we could be placed in a similar category.
Now, the fact that Apple has blessed a project with this much transparency represents a major break from tradition-- typically, Apple's software projects have been opaque to the outside world and very secretive. But they've evidently realized that when it comes to web browsers, there's no substitute for the grass-roots input of millions of demanding users with their own stringent standards. This certainly can't hurt Apple's credibility any. After all, what so many engineers (and others) crave-- even above proper immediate functionality-- is transparency into the process. This is something with which we contend daily at work; management looks at our team's products as a rock, and they don't dispute that we deliver a great rock, or that we do so consistently. But the problem is that this rock-- good though it might be-- just seems to drop out of the sky, with no warning, no prior milestones. You can't plan around it. Sure, all the rocks have been good so far, but without the ability to predict from observation how good the next rock will be, how can you risk banking on it following the pattern? Many managers will take a mediocre rock that they can watch being made over a stupendous rock that just falls out of a chute into the Shipping department one fine day.
Part of the mistrust that so much of the computer industry has built up for Apple over the years has to do with Apple's inscrutability and opacity. Sure, they have to keep things secret in order to do all the Insanely Great showmanship and everything; that showmanship is integral to the "style" side of the business, without which Apple wouldn't have the business case it does, like it or not. But there are some projects where they just can't afford to be opaque. Web browsers aren't sexy things; and while Safari is a great-looking piece of work, with a super-cool paint job and awesome handling in the canyon twisties, all that stuff doesn't mean a thing if it can't satisfy the needs of the millions of people for whom web browsers have become indispensable, utilitarian pieces of equipment. Those kinds of products rely critically upon user confidence; and that confidence won't come about, and especially not quickly, if the project is shrouded in secrecy. It's transparency itself, even more so than product quality, that will give people the reassurance they so desperately want.
Hence the almost puppy-like fawning contact with the KDE team two days ago, and the pledges for bidirectional open-source cooperation, and now Hyatt's blog (which I'm sure isn't the only such portal into the development team's brains). It looks to me as though Safari has nowhere to go but up; much of the initial derision of "just another marginal browser" and "another also-ran doohickey from Apple" has faded in favor of genuine well-wishing, for which I think we can credit this conscious public pledge of good faith. It seems that more people are arriving at the opinion that if some browser is going to turn out to be a heavyweight contender against IE, and one with a real chance of gaining some ground, they wouldn't mind it being Safari.
The grass roots are digging ever deeper...
BY THE WAY: Safari is fully AppleScriptable, as J Greely points out.
|
|
