The KHTML library (as wrapped by KFM) was surprisingly usable back in the day on Linux. But who'da thunk it'd turn into one of the most important pieces of code in the world? Congrats to all involved.
Wikpedia has one paragraph at http://en.wikipedia.org/wiki/WebKit#Origins "However, the exchange of code patches between the two branches of KHTML has previously been difficult and the code base diverged because both projects had different approaches in coding."
I can't comment on the state of things today, but I was active an active KDE core developer at the time from that original message to the time of the Zack's blog post (and I'm friends with both Dirk and Zack):
There was a huge amount of excitement at the announcement that Safari would be using KHTML. At that time, it was almost a given that the OSS rendering engine was Gecko. KHTML was KDE's little engine that could. But nobody ever expected it to be picked up by other folks. One of the original parts of the KHTML-to-OS X port was KWQ (pronounced, "quack") that abstracted out the KDE API portions that were used in KHTML.
Folks were pretty ecstatic at first. It seemed very validating.
But that changed quickly. As Zack's post indicates, WebKit became a thing of unmergable code-drops. Even inside of the KDE community there became a split between the KHTML purists and the WebKit faction. They'd previously more or less all been KHTML developers, but post-WebKit there was something of a pragmatists vs. idealists split. Zack fell on the latter side of that (for understandable reasons: there was an existing community project, with its own set of values, and that was hijacked to a large extent by WebKit).
A few years later WebKit transformed itself into a more or less valid open source project (see webkit.org), but that didn't close the rift in the KDE community between the two, at that point rather divergent, rendering engines. There's still some remaining melancholy that stems from that initial hope and what could have potentially been, but wasn't.
It's hard to argue that WebKit being open source has been a bad thing -- in fact, I don't believe that in the slightest. But I can also understand that it's pretty head-turning to have have a project transform in that way, especially for the original contributors (though, it should be noted, the original author of KHTML, who wasn't really active at the time of the transition, did eventually fall into the WebKit camp).
Final note: this is just my somewhat fractured recollection of things from being in KDE community. My contributions to KHTML / WebKit were very minor (the original spellchecking support) so this may not jive completely with the folks that were closer.
This matches my recollection of things as someone that followed WebKit from shortly after Safari was announced, and became actively involved when the open source project proper started up in 2005.
Safari, Chrome, all the non-Windows phones (iOS, android, bada, blackberry, and webOS) and some lesser uses. I think some of the embedded Netflix implementations use it.
Apple paid someone to hack on KHTML (In a most unfriendly manner) and Safari somehow becomes some of the most important code on the planet? Apple fans are a bit delusional.
If Safari magically disappeared today Mozilla would notice a bump in downloads and everyone would go with their day.
What exactly is your argument, that it's not important because people could use something else if they had to? Does anything qualify as "important" with that definition?
There seems to be some confusion about what "it" refers to. You keep referring to Safari. The original poster referred to KHTML, which for most intents and purposes "turned into" WebKit. That's how I and apparently most others understood him to mean.
WebKit, the rendering engine originally used in Safari (not Safari the application), nowadays powers Chrome, iOS, Android, BB and a hundred other browsers/platforms. In simple words: the absolute majority of mobile browsers use webkit, plus >50% of desktops/laptops.
There is a strong sense, even among ex-Apple employees, that the company's secrets are not for sharing. As one person's fascinating anecdote is another's secret, most tend to keep circumspect. Too, it's fairly common for ex-Apple employees to come back to the mothership, so there's also a "don't burn your bridges" aspect to the whole thing.
I hold hope that one day we'll have a folklore.org equivalent for the period where Steve returned to Apple up to the iPhone or thereabouts. Even a "Soul of a New Machine"-type book about the development of some products (iPod, iPhone, OSX) would be interesting.
In either case, Don, thanks for these stories. Any insight at all into how the sausage gets made is a great read.
People may have heard of "Rock Family Trees" - you look at the members of bands and trace backwards (and forwards) to see all the other bands involved.
Those family trees are fun. In a different life when I worked in one particular small, tight-knit industry I took a large whiteboard and traced each employee outward. That was a lot of fun.
I suspect in the case of Apple, however, that there would be a lot of circular loops many times over. =)
Safari is one of the best browsers I've used. It led to a better web development. If it weren't for the webkit, the might look like it's stuck in the 1990s.
I'd like to hear about how WebKit went mobile for the iPhone. Eg if Apple worked with Nokia and their port of WebKit to Symbian, or started their own port from scratch.
WebKit was open sourced roughly a week (June 7, 2005) before Nokia announced the port to their phone (June 13, 2005). That means that Nokia was able to do the port in less than a week with (presumably) a few competent developers.
As the other person said, you must be kidding if you think Apple worked with Nokia.
Did you read any of the posts that have been flying by?
WebKit was a project shrouded in almost total secrecy until it's announcement as Safari and was clearly done at Apple and based on KTHML/KJS.
Not only that, what would make the mobile version "special" (besides dealing with touch input and screen resolution)? Don't you remember Jobs' comments about it being the "full" internet?
Going further, why on Earth would Apple even hint to Nokia that they were working on the iPhone?
> WebKit was open sourced roughly a week (June 7, 2005) before Nokia announced the port to their phone (June 13, 2005). That means that Nokia was able to do the port in less than a week with (presumably) a few competent developers.
While the ex-Nokia developers I've met have all been excellent engineers, they certainly didn't port WebKit to their mobile devices in under a week. June 7, 2005 marks the date that Apple started WebKit as an open source project. That is, on that date the CVS repository and Bugzilla instance were made publicly available. For over two years prior to that point Apple had been publishing the source code of the two main components of WebKit, JavaScriptCore and WebCore, alongside Safari releases. Nokia's port of WebKit to Symbian was based on those releases, and it wasn't until late 2006[1] that Nokia started developing against the current WebKit SVN repository.
Fair enough. But the point remains that I doubt Apple would have needed Nokia's help porting their own code to their own secret platform. It would have been commercial suicide practically to let a competitor know.
AFAIK, Nokia started work on making WebKit mobile before Apple did (I could easily be wrong). There was presumably a fair amount of work making WebKit work well on mobile devices so I'm wondering what influence Nokia's port had on the iOS port. Perhaps Apple completely ignored it or perhaps they only put WebKit on the iPhone because of Nokia's work.
I wonder, too, how hampered Nokia was by trying to port it to an existing platform, presumably striving for a lot of backwards compatability. Nokia, at the time, had many popular handsets available, of varying power/capabilities/providers. Apple was designing a new phone, a single piece of hardware, a single provider.
Obviously the products may be been developed much earlier, but the Webkit browser on Nokia N95 was released to the market before the iPhone was released in 2007.
WebKit core gets commits from nearly every major hardware manufacturer and OS vendor that isn't Microsoft. Unless Apple's stripping all those commits out of spite, iOS WebKit contains code from Nokia, RIM, Samsung, HPalm, Google, and many others that might be seen as competitors otherwise.
Adobe is more or less neutral, though (they just want you to buy their tools). Apple, Nokia, RIM, Samsung, etc. all would very much like the others to cease existing; yet they're all contributing to a project that keeps each other on a level playing field (in the context of HTML/JS engines, anyway).
I think the point is that Apple didn't treat Safari/Webkit as being a competitive advantage so much as nullifying a competitive disadvantage -- it was a defensive play, not an offensive play. (A nice analogy is Android, which Google developed out of fear they would miss out on the mobile market rather than out of any desire to "own" the mobile market. Google didn't want Apple or anyone else to own its destiny, just as Apple didn't want Microsoft to own its destiny.)
Don, a great blog post! It's really fascinating to hear about what goes on between the inception of a project and its release at an Apple keynote.
I would be interested in hearing more about the technical side of WebKit. How does it work at a high level? How are touch events handled? What fancy things are done (within your NDA restrictions) to make scrolling so fast on the iPhone? It would be really awesome if you wrote a series of blog posts talking about the structure of WebKit!
Too late! The feature was removed (I think quite some time ago). Ok, admittedly it’s still there in the menu, but no longer given any space in the UI.
I understood what it was but I also never used it. It sounds useful, but somehow isn’t for some reason, at least that’s the case for me. I wonder whether there were ever any number of people who really used the feature.
That also goes to show that just having a useful feature isn’t enough.
I think the problem with the feature is that it isn’t useful often enough. The common case when looking at search results is to open a page, see that it isn’t the right one and go back. So just hitting the back button once is quite often all that’s needed.
Sometimes you will click through several pages before you notice that what you found isn’t quite right, but I would guess that in a majority of cases you will notice that immediately. Which means that just hitting the back button just works in a majority of cases and the Snapback function doesn’t provide any additional savings.
Moreover, the back button is probably the single most used UI element in a web browser, so everyone is really used to using it. Switching to something else that does something similar in some situations but you are not used to is a painful transition.
Also, the back button degrades gracefully: Just slamming on it until you are back where you want to also works. It might take a little more time, but it works.
So in summary, the Snapback function is only rarely actually useful compared to the back button, and if it is the back button requires only a little more effort but also works. That’s why I think it doesn’t really work.
Chrome implemented this by showing the last history item with a different host at the bottom of the list that shows if you hold down on the back button.
No wonder, the button was way too small. I was used to click it a lot, and I still miss it today. But before hitting the reply button I googled and found this extension [0]. I'm happy again.
BTW, hey Don I love your writings. Please keep writing and posting. Thanks for WebKit too!
Don, i am trying to understand why you (not you in person but Apple) went the open source route for safari but not for itunes etc.
Can it be that, at that moment when you made the decision, web sites 'made for internet explorer', were too many. And you wanted the rendering engine on Mac to be widespread by getting from and giving to an open source project.
Here's a great story from Cabel at Panic about how Apple approached them to purchase Panic so they could turn Audion into iTunes. Instead, they went with SoundJam:
Most likely because KHTML license was (still is) LGPL, which allows the creation of proprietary products with it (Safari) but requires all source code changes to be published.
Had KHTML been licensed under a BSD or MIT license, the browser world could potentially be very different from what it currently is.
Same reason that most companies that go open-source do so: because they were innovating from underneath, entering a market with much more dominant players. Would Android be open-source if the iPhone hadn't been so dominant at the time?
iTunes started out as a third-party playlist manager whose name escapes me (I even owned a copy). It's perfectly possible that it included licensed code that couldn't be open-sourced even if Apple wanted to do so.
Next, Apple was only able to negotiate licensing deals for music (and later video) content from the various rights holders after agreeing to various strictures including sufficently restrictive DRM and functional restrictions such as allowing music to be copied only from computer to iPod and not from multiple computers to a single iPod.
Apple didn't try to stop third parties from working around some of these restrictions but it couldn't be seen to be allowing them to be circumvented willy-nilly and open-sourcing iTunes would immediately lead to a "rip everything to MP3" and "grab everything from all attached devices" features.
Apart from the legal reasons that may have forced them to do so, they also got other people contributing to the codebase and fixing bugs. Other companies can also use the component, which is a great thing for a rendering engine - it will get more popular and websites will have to test and optimize for it.
Regarding iTunes, Apple wouldn't want anyone to release a competing program. You could probably outsource some common libraries/components, not sure if this is done. But anything specific will not be used or improved upon by others anyway, so there would be no benefit in opensourcing it.
1. iTunes started out as a music player. The iTunes Music Store came later. You can debate whether or not Steve was planning the iTunes Music Store from the beginning, but that's neither here nor there.
2. iTunes, at least in the beginning, was just a wrapper around the QuickTime framework.
"2. iTunes, at least in the beginning, was just a wrapper around the QuickTime framework."
There's more to it than that, but this touches on something; I really wish that something akin to QuickTime was available cross-platform. Yeah, it's crufty and strange warts that reveal Ugly Things are all over the place, but man, having a good AV API would make a lot of things better.
ffmpeg is a very impressive achievement, but it's not the same thing.
The mention of needing to keep the project a secret makes me wonder what would have been so different about things had the news leaked.
Let's say the browser user agent leaked or some enterprising reporter figured out what Apple was up to. What would have gone differently in that alternate universe?
Probably some bad things, over the years certain project details have leaked right before the keynote (such as ATI pre-announcing a hardware release) and finding Apple switching to NVIDIA for the next few years.
What happened to KWQ? This looks like a great starting point when you want to port some KDE/Qt lib to native Cocoa. For example, I'm thinking about KDevelop, Amarok or others.
We built our own browser because we didn't want to depend on another company for a critical application.
We built our own browser engine because we wanted to use the technology in more things than a browser.
We built that engine small and fast because Bertrand Serlet would have shot me if I had done otherwise. :)
Apple had been dependent on Microsoft and Netscape for good browser options. Microsoft released IE5.5 for Mac which was neither IE5 nor IE6 compatible, and then nothing. Netscape gradually turned into a gigantic steaming pile of crap.
I might add that Chimera -> Camino was the beacon of hope before Safari came out, and once it got going on Mac OS X, other folks got so excited they demanded a cross-platform version which eventually became Firefox.
In general, the need for a non-sucky non-bloated web browser alternative to IE reached a critical mass at that time, not just on Mac OS X.
"I might add that Chimera -> Camino was the beacon of hope before Safari came out, and once it got going on Mac OS X, other folks got so excited they demanded a cross-platform version which eventually became Firefox."
I'd never heard this and I can't seem to find any references to it. Would you mind pointing me in the right direction?
As mentioned in the story Dave Hyatt was the main guy behind Chimera, (a streamlined platform native browser using the gecko renderer but ditching mail, composer etc. from Mozilla Suite) and with Blake Ross, behind Phoenix, which became Firefox (a streamlined platform native browser using the gecko renderer but ditching mail, composer etc. from the Mozilla Suite).
Technically, they were both faking the platform native element to some degree, but they were at least trying to fit in with their respective target platform(s).
It is ironic that the only Apple product we're getting an overdose of play-by-play insider information about development and launch is the one people care the least about: Safari.
As pointed out earlier in the thread, the significance is not Safari but WebKit, which is now used by the majority of the software that is used to view web content. The reason WebKit was originally developed is Safari.
Wow this is really great. Safari use is increasing all the time. KHTML originally came from KDE of Linux fame, and has good support for most HTML standards, making it a wonderful language to start with.
it not so fast as chrome, not have so many productive add-ons as chrome and firefox, not so flexible and customizable as firefox, not so open and powerful as firefox.
right, so what mcot2 is saying is that you're using most of safari anyway. safari was just a thin shell on top of webkit. I'm sure apple spent most of it's time improving webkit and not much time making the UI shell around it.
So I'm curious. As a young programmer with 1.5 years before entering the workforce I have to wonder what you plan to do. From my super young and inexperienced perspective retirement will just mean having more control over my programming. Is programming still super fun and adicting?
So; what do you plan to do? A relaxed retirement? Occasional contracting? A startup? Open source? Quiting programming forever and travelling? Something a lot more reasonable than this false dichotomy?
From his website: "Hello, I'm Don Melton, probably best known as the guy who started the Safari and WebKit projects at Apple. These days I'm just an aspiring writer and a recovering programmer."
