I'm not the only one who dislikes KHTML's rendering in Konqueror, as the call for WebKit integration into Konqueror is a strong one. It makes sense, too; WebKit is a fork of KHTML, and over the years, WebKit has simply become the better of the two, with major backing from companies like Apple and Google, among others.
Adam Treat, who works on the QtWebKit KPart, and has worked on its integration with Konqueror, now explains that Konqeuror is simply too tied into KHTML to even work properly with the QtWebKit KPart. "Plumbing the sources of Konqueror I learned a nasty secret: Konqueror is highly KHTML API specific," Treat details, "Konqueror has deep integration with KHTML that goes far above and beyond the KPart API. Creating a QtWebKit KPart is woefully insufficient for the purpose of providing anything more than a basic HTML viewer."
That's not good enough, obviously. He further explains that if the KDE community wants a QtWebKit browser, they better look beyond Konqueror. "Otherwise you are left with two hacky solutions: make a QtWebKit KPart that is API compatible with KHTMLPart OR migrate Konqueror source to make it less dependent on KHTMLPart," he says, "The former is not going to be fun as the KHTMLPart API is not refined or polished and highly KHTML specific. The latter can only be accomplished with a lot of work set aside for refactoring or through nasty '#ifdef KHTML callThisWay() #else callThatWay();'."
If you don't like KHTML, then there are two solutions if you're running KDE: Firefox with KDE integration, or a proper WebKit browser written in Qt. I'm personally no fan of Firefox, so the latter option seems more attractive to me. Such projects are already under way in the form of ReKonq and Arora.