So after my last post I investigated a bit.

First I have to say that C++ is NOT a problem. It is perfectly possible to provide API for C++-incompatible applications/developers. It does not matter what is the underlying language, even more when said language integrate very well with the existing C framework.

Dobey:

You clearly don't know about KHTML. KHTML4 as of today is in the WebKit repository, that same WebKit from Apple. It is called Unity and is the result of the cooperation of the WebKit developers at Apple and the KDE people.

On MacOS, for example, WebCore does not hard-depend on Qt, even less on KDE. Even if it were, I would still consider a Qt dependency less a problem than, for example, Mono or Python. GtkWebCore is dead, and there is actually Gtk support in WebKit. See for yourself. And that is where the future lies. The current status is "sort of work", ie you can display pages, but you miss forms and other things.

As of GtkHTML, it is not because it is used that it is a good solution. The lack of support for recent web standard is probably its biggest problem. And bringing that on par is probably more work than one might expect. The Web is a huge mess. Going towards fixing GtkHTML is probably doomed to failure. Wasn't GtkHTML originally a rewrite of KHTML in a non object oriented language? And clearly the easiest route is to finish the port of WebKit.