Situation around KHTML and WebKit finally settled

As it was now revealed the situation around KHTML and WebKit is settled. KDE will focus on integrating WebKit into the system while also implementing all yet missing KHTML features into WebKit.


WebKit is a KHTML fork done by Apple some years ago. Today it is developed not only by Apple but also by Nokia, Adobe, Trolltech and many KDE developers. There is even a basic Qt port which can be run under Linux.

At the same time, KHTML development continued since the mentioned fork. Some of the development efforts and results were shared with WebKit, others were not. The main problem was that Apple needed quite some time to learn how to interact with Open Source developers and projects. They did not violate the licence, but they behaved pretty rude, making it often impossible to really incorporate their patches and changes.

The question was now if KDE should (also) adopt WebKit or stay with KHTML.
WebKit offered the advantage of more parties taking part in the development as well as more coverage and a wider spreading of the engine itself. However, KHTML offered the advantage of having an in-house solution which is under total control. Also, there were/are still some bad feelings towards Apple left among some developers because of the way Apple acted in the past.

Therefore the plan was originally to keep KHTML and provide a kpart solution of WebKit as an option. This was developed and was expected to be ready around KDE 4.0 or KDE 4.1.
The result would be to have a co-existence of both, with KHTML as default and WebKit as an option.

The new situation

Now Troy Unrau unveiled that the developers discussed this topic at aKademy 2007 in detail – and settled on WebKit for the long term:

While there are still a few reservations, the consensus is to develop a Webkit KPart for embedding into Konqueror at the earliest opportunity and to take a more active role in the development of Webkit itself.

All features yet missing in WebKit are supposed to be integrated with WebKit, making this more a merge than a switch.

This will certainly give KDE browsers better support from web developers since more people will be able to test with WebKit (because it is wide spread) than with KHTML. Also I’m quite sure that having so many parties developing together will push the development of the engine quite a lot – I would not be surprised if WebKit would become the most standard compliant browser available.

The technical interesting thing is that most KDE users will not see any difference: due to KDE’s excellent design it will be possible to use Konqueror with WebKit without any differences. It will just seamingless integrate with Konqueror and all other applications which use kpart to display html pages.
Also, development wise not too much will change for many KDE developers. Quite some work was already done within WebKit by them, so they are already used to develop WebKit.

Of course the integration still have to take place. At the moment KDE 4.0 is very close to the first Beta release (which is scheduled for July 25, which is tomorrow!) and therefore there should be no new features. On the other hand discussions are under way to slip the Beta date by one month and to publish an Alpha 3 at the 25th. With such a slip of the release date we might even see WebKit as a default kpart in Konqueror in KDE 4.0. I think this will be made clear the next days.

4 thoughts on “Situation around KHTML and WebKit finally settled”

  1. Liquidat,

    Just a bit of nit picking but you might want to correct the following:
    “the most standard complaint”->”the most standard compliant”.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: