KHTML And WebCore

This a draft paper on the differences between KDEs KHTML used in Konqueror and the WebCores KHTML used in Safari. For the rest of the page I will just call the two KHTML and WebCore.

History

In january 2003 Safari and its KHTML 3.0 based rendering engine WebCore was announced. Since then WebCore has developed and changed a lot. Because of the LGPL license of KHTML Apple has also released all of its changes, but they have not worked actively to keep the two projects in sync. Suggestions to maintain a common CVS or codebase have failed, and with a "diff" of more than 100000 lines today; WebCore is in reality a fork.
For some time the WebCore development seemed to move much faster than KHTML. Maybe beacause Apple had 3 people working full-time on it and KHTML had maybe 3 people spending some of their spare time on KHTML among other projects. Since Safari 1.2 though, development seems to be at a more leasurely pace at Apple, and new fresh developers have joined the KHTML crew (It is possible Apple have just made the project more secretive).
Despite many differences, KHTML and WebCore still share a common foundation and new features and fixes are ported both ways. This is what makes it interesting to try and account for the differences and similarities.
I will here list all the differences I know about. Anyone knowing of more difference are welcome to write to me so I can update the list. I will try and account for 2 version of each project: KHTML 3.3.2 which is KDEs stable-branch and KHTML 3.4 which is KDEs current development branch. WebCore-125 which is used in Safari 1.2 and thereby the last used WebCore release, and WebCore-146 which was "released" to give the community some insight in how the Dashboard extensions are implemented.

Common features

The KHTML version branched to WebCore had full HTML4, DOM1 and CSS1 and most of DOM2 and CSS2 features, later more CSS2 features and a few CSS3 and DOM3 features have been added.

CSS2

While both KHTML and WebCore has almost full CSS2 support, they share a few comment missing features. Generated content with quotes and counters, most properties for paged media and all properties of aural media. Both engines also ignore most styles on form-elements.

CSS3

Safari and Konqueror both follow the recommendations on new standards, which means that CSS3 standards that have only been described in working draft documents recieve a -khtml- prefix when implemented. While standards in Candidate Recommendations are implemented without prefix.

DOM

FIXME: All of DOM1, how much of DOM2 and DOM3?

User-Agent Detection

To detect Konqueror search for the string "KHTML" in the UserAgent, to detect Safari search for "WebCore" in the UserAgent. No common detecting have been agreed upon, but to detect both you can try searching for "like Gecko" which are contained in newer versions of both UserAgent strings. To detect a Konqueror that is spoofing as a different browser, check if Vendor string is equal to "KDE".

Safari > Konqueror

The team behind Safari and WebCore has first focused on better standard complience and then a number of key technologies they either needed for various projects or because it helped the general Apple==eye-candy impression.

To list a few:

Konqueror > Safari

Development in Konqueror is not standing still either. The classic advantages of Konqueror is its integration with KDE, which among other thing gives access to a very powerfull component model and many plugins. Konqueror therefore has the ability to present more configuration options and more features than Safari, and can be customized by both vendors and end-users to look and behave as they please.
The development in KHTML is also branching somewhat. Several developers have expressed that it is more fun to implement new feature themselves than merge bug-fixes from Safari. Never the less many fixes and features are rutinely ported from Safari. If a users finds things that work in Safari and not in Konqueror they are more than welcome to specify so in bug-reports on bugs.kde.org.