[michael_miller]

I suspect the reason for choosing KHTML over Gecko may have been more political than anything else. Since Mozilla was the dominant non-IE browser at the time, it would be hard to justify any fork to the community without meaningfully given back. For example, Apple could go off into a cave and add touch handling support with momentum scrolling and GPU acceleration, and the Mozilla community would be absolutely furious with Apple for creating effectively unusable work, assuming they did the work over several months/years in secret. The last thing Apple wants is a large group of loud people complaining about itself.

By comparison, KHTML was not really a serious project. It had a few developers, but nowhere near the scale of what Mozilla had. Thus, when they forked it to do their work in secret, only a couple people complained.

[ryandvm]

> By comparison, KHTML was not really a serious project. It had a few developers, but nowhere near the scale of what Mozilla had.

You'd be surprised at the negative impact that a large number of developers can have on the quality of a software project.

[Someone]

When Safari came out, I happened to just have looked at the Mozilla code. A significant part of the "scale of what Mozilla had" was due to the design decision to couple the major browser components using a home-grown (and, hence, included with the sources) clone of Microsoft's COM.

To make matters worse, unlike Microsoft's version, the Mozilla version needed to support multiple OSes and multiple compilers.

Because of that, I believe Apple's claim that the choice for KHTML was on technical grounds.

(I don't remember whether Mozilla already used XUL at the time. If so, that could have been another argument for choosing KHTML)