CNET Opines on Apple's Choice of KHTML

Tuesday January 14th, 2003

CNET has an article about Apple's choice of KHTML over Gecko for its Safari browser. Featuring a variety of quotes from many high profile figures, the article goes as far as to call the decision a "snub" — a claim that Apple's spokesperson refuses to corroborate.

Update! Mike Shaver isn't too happy about being quoted out of context and Chris Blizzard also has some choice words about the article. MozillaZine founder Chris Nelson isn't quite so subtle. There's also a discussion at Slashdot.

#3 Safari developers' backgrounds

by sethf

Tuesday January 14th, 2003 12:07 PM

You are replying to this message

Finally, an article that fairly (if incompletely) mentions the backgrounds of the Safari team.

Dave Hyatt (I mention him first, as he is more tied to the Mozillazine community) was a Netscape employee and (to the best of my knowledge) remains actively involved with the Mozilla codebase through development of Gecko, Chimera, and Phoenix. Up until last Tuesday's announcement, I had assumed (along with much of the world) that his employment by Apple and his continuing work meant that a Gecko-based browser was being produced by Apple. Up until KHTML appeared on Jobs' Keynote slides, I was expecting the next word to be "Mozilla" (or Gecko).

Add to this the fact that the rest of the Safari team (including former Netscape employee Melton) hails from Eazel (whose Nautilus was heavily dependent on Gecko) and it's impossible to say that Gecko was never considered. Each and every member of the Safari team has *extensive* experience with Gecko. Why would this team (of all browser developers) pass Gecko by in favor of KHTML if they didn't believe that KHTML was a better fit (note: not necessarily better) for the goals of Safari?

KHTML will no doubt improve as a result of this partnership. It may eventually be a competitor in all senses to Gecko, but as long as the goals of each project are different, there will be a place for both. If nothing else, competition between the engines (fully supporting standards, correctly) will prevent stagnation and promote innovation and will end up making the world a better place for web developers.