froglogic / All / The KHTML Future FAQ

The KHTML Future FAQ

As people on #khtml and elsewhere keep asking the same type of questions I will summarize some of the answers that I can give and which – to my best knowledge – should match the view of other maintainers. This is to inform contributors, bug reporters, other helpers and users about the current state, avoid unfounded irritation and provide the basis for further discussion.

Feedback is greatly appreciated and will be incorporated into an updated version to be placed on or so.

Will KHTML be the HTML rendering engine in KDE 4.0?

Yes. We are currently working on polishing it to get it into shape after so much of the frameworks around it have changed.

Are there any plans to drop KTHML?

No. Despite rampant rumors floating around there are no such concrete plans. We have had several discussions about alternatives but none of the them has yet crystallized as being accepted by the majority as a real option for KDE.

Why don’t you pull all the good patches from Apple’s WebCore and JavaScript libraries?

We do that to a certain degree since the beginning. More for KJS than for KHTML which is much bigger and platform dependent. Apple’s code repository is publicly accessible now which has eased patch extraction. Prior to its opening the code had already forked a lot, unfortunately. Misaligned release schedules, design conceptions and platform needs have also sometimes resulted in incompatible solutions.

Are KDE patches ending up in Apple’s code base?

To a small degree only. There were several attempts to establish a tradition of feeding our patches. Apple engineers also sometimes cherry-pick performance improvements on their own – possibly way later than we published it. As the patches at the same time often get reformatted to fit their coding style this does not make the “diff”between the code bases any smaller. As changes never get pushed back to us this is not an overly satisfying experience.

Does KDE profit from Apple’s work?

We do in many ways. There are not only improvements and bug fixes that we can adopt but also an increased public awareness of our work and a group of skilled engineers to exchange ideas with. On the downside we are competing for independent contributors and have to live with the fact that some prefer to team up with a shiny and mighty company as opposed to joining our multi-faceted desktop project.

How about joining forces?

This is the obvious solution, of course, and since the beginning there have been various initiatives to establish a common project. So far all such attempts have failed. One has to realize that the Safari team is constantly under immense pressure to produce new features and benchmarks for the next Mac OS X release or whatever Steve Jobs will present at next year’s WWDC keynote and does not want to risk giving up full control. As with the Windows version of Safari, work is sometimes done behind the scenes. We have not given up hope of course and hope to find some solution that accommodates the need of all

Why is all of this important?

The attention paid to KHTML and interest in its future is amazing. The number of well-meaning advisors by far outweighs the number of developers actually writing the code. But the interest is fully warranted. The use of Internet technologies will inevitably continue to rise in our applications. And the degree to which we are involved in the development of these technologies will govern our freedom in advancing their use. The Web development environment Quanta built on top of KHTML is such an example. Further opportunities for our mail mail, IRC, blog, news, media, calendaring, messaging and you name it clients are sheer endless. Merely adding a GUI around ready-made 3rd party components will not add much extra value to our framework.

What are maintainers asking for?

To be able to satisfy our user’s expectations we need to be able to provide a patched version in case they find a bug. This is
particularly important in case of security problems. This requires access to the development repository as well as KDE producing packages out of that repository. Waiting for other vendors to ship bug fix releases is not an option. When it comes to development of new features KDE developers need to have some say into it even if it needs to be coordinated with other parties. In case of KDE-specific needs there needs to be some way to add them.

Isn’t this all a rather trivial job?

A Web browser component is about more than plain HTML rendering. Apart from dynamic scripting there is Java, Flash, cookies, URI shortcuts, password managers, security and networking support. And KDE has invested a lot into providing this infrastructure that is being shared with other applications.

How about using QtWebKit ones it comes out?

QtWebKit is a port of the forked KHTML sources that aims at providing a ready-made HTML component to Trolltech customers without relying on KDE (other than incorporating the WebKit sources with KDE origin). It just is yet another platform port without any influence on the feature set and therefore useless for KDE’s purposes. See the “Why is all of this important?” and “What are maintainers asking for?” questions for more details.

So what are the plans?

As the current alternatives would mean dropping our code and losing all influence on development these are not real options. So we’ll simply stick to our code base for now and keep on merging in improvements ourselves. The code is pretty good, surpassing other browsers in speed and features in some areas.

Of course, we would be very much interested in joining forces with others having the same development goals. And we’ll keep the
discussion about cooperation going. One approach I could imagine is to merge our work (thousands of commits done over the recent years) into a WebKit branch and switch over to that one day. This wouldn’t be a branch like Nokia’s that diverges from the main line more and more. Instead we could branch it off trunk regularly and simply re-apply our KDE-specific patches.



Niko: that’s exactly the reason I’m in favour of using WebKit – as good as possible. It would simply benefit the users most. And “WebKit” does have a capital K in it, so it’s KDE enough 😉

Lets just hope the remaining kinks can be worked out.nn1

Kongratulations for Your descision!

I also think, that it’s better to merge some interesting code from WebKit to KHTML AND by the way, review the code …
Knowing, to be in time to market, the first solution may not be the best, but you’re in time (WebKit). So i think, that if you would take WebKit, you will at the long end spend more time to fix code, than to implement clean code …

best wishes and thank you all for your work!!!

20times later, reloaded the site twice again, because i’ve testet als variations of the code, i’ve found the right security code 🙁

There is only one feature why I would choose QtQWebKit instead of KHTML. That is contentEditable/designMode. I got used to these nice WYSIWYG editors for working with a CMS.

Many Web Developers test their pages in several Browsers: IE6, IE7, Firefox and Safari. Some on Opera. But not too many have a linux machine just for testing in Konqueror.
And: they don’t get payed to make things work in konqueror!

Almost all simple pages work without any problem – but some of those ajax pages do not. (gmail is a perfect example)

If Konqueror would use WebKit (and identify as WebKit – so those browser-sniffers get something they know) many problems would be solved.


I agree with Niko. No one who does website design needs yet another browser core to test against. They won’t bother with Konqueror. What is wrong with using QtWebkit? I think it is a foolish decision that ends up marginalizing KDE. The first thing I do on a KDE install is to install Firefox and configure the desktop to use Firefox for default. That is because I need it to work with a variety of websites. Konqueror does not. But considering QtWebkit would be the better route.


Why not use Firefox only then? There is/was a Qt port, too. The predominance of other software has luckily never stopped their own efforts. Our would you have preferred Matthias Ettrich not starting the KDE project because Windows was already there?

As I said, of *course* we want to work on a single code base. Pride is really not the issue here. It’s just not trivial to set up development that can actually be performed keeping KDE in mind.

Not that your FAQ doesn’t sound reasonable enough, but do remember not to engage double standards for KHTML and Apple. Getting this issue sorted out not only means that Apple needs to make compromises, but you also need to do so.

If you just demand each and every advantage of KHTML to be kept without compromise, you might lose sight of the greater good which is higher development speed due to combined efforts, and more importantly a browser that works correctly for KDE users on far more sites than a separate KHTML ever will, no matter how much cherrypicking is done.

Considering that an editing mode for Quanta is the only real technical issue that can’t be done with a QtWebKit of today (if I’m correctly informed), have you even done a serious effort to get those improvements into WebKit? I really can’t believe that they don’t accept well-done code, no matter how release- and feature-driven they might be. Especially with a load of KDE people being there in reviewer state as well.

Nothing’s gonna be perfect, WebKit just as little as the original KHTML. So please take more into consideration what’s the best thing for KDE users and developers, and less how all the KHTML features can be kept. If the original KHTML, as depicted in your FAQ, is the right thing for the former as well, then by all means go for it. If not, do quickly find a solution on how to rebase KHTML off of WebKit, or let Zack & friends do their thing.

Zach Rusin just burned you. Go read his blog.

ahh, the joy of trying to work with a corporation :/ I don’t understand why most of the commenters seem to be assuming it’s KDE that wants everything their own way, when from what I’ve seen they’re the ones trying so hard to find a way to co-operate.

niko: afaik, that’s simply not true; webkit has its own issues. it would not magically solve everything, and since it’s controlled by apple, the KDE guys would have a much harder time trying to actually make any kind of improvements or bugfixes. forked code is not fun.
also, gmail actually works best when konq identifies as firefox – why the gmail team refuses to just give browsers identifying as konq the same code as ff is beyond me.

anyways, I’m sure there’ll be a webkit kpart available at some point, so then you can try it out and see for yourself whether it’s preferable to khtml.

since konq will probably be available on windows soonish, that’ll make it theoretically possible for windoze-only web developers to test it- but I don’t actually think that will help much, because konq just plain sucks for debugging. I think it’d be useful if someone who knows what web developers want were to work on making konq more usable to them.

> and since it’s controlled by apple, the KDE guys
> would have a much harder time trying to actually make any kind of
> improvements or bugfixes. forked code is not fun.
what about a KDE-branch that merged from time to time with the apple-branch? I guess apple branches too for Safari 1.3 and 1.4 etc…

> I think it’d be useful if someone who knows what web developers want were to
> work on making konq more usable to them.
That I can tell you – the best web-developing tool ever is Firebug. If Web-Developers could be helped working with Konqueror then with a similar tool/plugin/whatever. (Konqueror has a JavaScript Debugger and a DOM-Viewer – but you can’t really compare them with Firebug)

As a KDE user: please give me the choice between Gecko, WebKit and KHTML rendering engine in Konqueror. Best option would be to switch on the fly for a loaded page – then I could find out quickly which engine fits my need best (and I could switch for problematic pages instead of starting another browser).

Go and provide options – don’t flame the other teams. KDE and Gnome coexist, WebKit and KHTML can do as well. I can use Gnome apps on KDE and vice versa, having that for rendering engines doesn’t seem bad to me.

KHTML is dead. Long live WebKit!

I love Konqueror, and spend most of my day in a Konqueror session, because of the easy access to ioslaves and the fantastic embedded document viewers.

However, I honestly believe that moving to Webkit would be the best thing to do for KDE. Why? Many eyes, many users. There’d be more people developing the HTML renderer, meaning that bugs would be fixed slightly more quickly and that it would be more likely to survive people losing interest in the project and moving onto other things. There’d be more people using the renderer, meaning that there would be a greater incentive for website owners to go the effort of compatibility.

We’d end up with Konqueror being just as powerful, but with better support from developers and website owners. And that can’t be a bad thing for users; quite the contrary.

On the other hand, *not* using Webkit as the engine would likely alienate users who expect KDE’s web browser to work well with all the websites they like to use, leading them to shun Konqueror completely, and thus miss out on its many awesome features — I know several such users personally.

What are the *downsides* to moving to Webkit as the rendering backend — given that a Webkit kpart already exists?

From the point of webpage compatibility, Gecko with its ever-rising share would be much better option – and its not controlled by corporation. It would be far more level relationship with… I know though, that Gecko has heavier (memory) footprint.

It is quite likely, that, form the reasons posted here, it would soon become necessary to fork (Qt)webkit again, meaning that Safari-driven compatibility with webpages would be lost again. Also note that Safari is less supported by pages than Firefox.

What is important is, that KDE must not let go control over the development of its central component – the html rendering engine. Spice must flow, as they say.

Btw. on KDE 4.0 API Reference KHTML page is written:

“KHTML is likely to be superseded by WebKit in KDE 4.1 / Qt 4.4.”

This is great! So there is really chance that KHTML will be replaced by QtWebKit in KDE 4.1 (despite injured ego of remaining KHTML developers).

Andreas: yes, it would be really great and unique feature! However, the question I cannot answer is, if it can be implemented. I do not know the codebase of Konqueror, but I can imagine that there might be some design differences which makes it impossible 🙁

Jakob: Of course we are willing to compromise. It might not be visible to an outsider but we already spent hours of patching, martyring our brain and discussions on that.

niko: A KDE branch sounds like the best option to me, too. Whoever added the doc entry must have been mislead by whatever talk picked up somewhere. Hence the need for the FAQ;)

I Know It Seems So Easy To Accept Webkit, But From The KDE Developers Prospective, If Apple Decides To Not Give Them SVN Access, They Can’t Make Changes, Which Screws Them Up Until They: 1) Regain SVN Access OR 2) Fork Webkit. As This Would Be Extremely Disruptive, Retain Control By Using KHTML Is The Best Option.

KHTML maintainers should have been a role model for freedom and openness value in Free Software by welcome WebKit along side KHTML as an option for distros/end-users. And there’s still time 🙂

I respect your decision. But you must realise, everytime there’s a bug in KHTML, everytime it misrenders a page. Everytime it is slow, or it crashes, people will say “WebKit wouldn’t do that”.

Not using WebKit is not to the benefit of KDE. That is not to say that KHTML should not live on. The best ideas come from active projects with different design goals. But the best option for the entire KDE userbase is for Konqueror to use WebKit. And you know it.

You don’t need to drop KHTML, what we want is WebKit support, that’s all we need.

Leave a Reply

Your email address will not be published. Required fields are marked *

Copy link
Powered by Social Snap