The topic of WebKit is not the easiest one. It's had its share of controversy and until recently QtWebKit wasn't really, at least in my opinion, quite up to scratch for production usage outside of fairly simple use cases. With Qt 4.6, which came with improvements across the board and new API for things like DOM access, it has turned a very important corner and makes the topic of "What does KDE want to do with QtWebKit?" ever more pressing.
When it comes to a web rendering stack, there are generally three kinds of uses for them:
- Web browser: this would be things like Konqueror, Firefox, Chrome, Internet Explorer, Opera, etc. They have one purpose in life, and that is to wrap themselves around a web content stack and give people the ability to "browse the web"
- Displaying XHTML/JS content from Internet sites inside a non-web-browser application: examples include the web or Remember The Milk widgets in Plasma, the Wikipedia content for geographical locations shown in Marble or the plethora of web based information shown in Amarok. These applications are not web browsers, and the content shown is highly specific and even pre-selected by the application developer. Done well, the user doesn't even think "oh hey, I'm browsing the web!"
- Displaying XHTML/JS content in a non-web-browser application that is locally generated: this includes things like KDE's documentation reader and the email viewer in KMail. These applications are using the web stack as a rendering system and little more. That you can fetch content from web servers on the network isn't too relevant and, done well, there are no "visible seams" between the "native" parts of the application and the HTML rendered content.
When it comes to WebKit and KDE, it is quite evident that it is in the latter two categories where it could have the biggest "footprint": there are simply dozens of applications that could be using it (versus our one web browser). They are also the easier topics since the usage of a web stack is simpler and more straightforward than in a full blown web browser. The conversation around whether to use WebKit in a web browser is not nearly as clear cut and we already have that conversation happening in the form of projects like Rekonq and Arora, in any case. So I'd like to focus on the non-web-browser application usage of WebKit in this entry.
As 2009 closed out, a couple of very significant QtWebKit events came about for KDE: the API around QtWebKit expanded considerably (the DOM API, for instance, which is often used in our applications now) and KDE WebKit was added to kdelibs. KDE WebKit takes QtWebKit and implements all the platform-specific integration bits, where the platform in this case is KDE. Things like KIO (and therefor the proxies set up in KDE's control center), KParts, cookies and more have been made available to users of QtWebKit as a result. These developments have made QtWebKit a serious contender for usage in KDE applications.
Of course, just because it exists is no reason to jump on the QtWebKit bandwagon. If we are going to use QtWebKit (or not), we need have reasons for doing so (or not doing so). We already have KHTML and it works rather well and is still under development, after all. Is there any compelling reason to use KDE WebKit in our applications instead of KHTML?
The Network Effect
We all know that WebKit, which was birthed from KHTML, is now used in several top tier web browsers and even more applications. Apple's Safari and Google's Chrome are both well known examples. This means that there are, relatively, huge numbers of people working on WebKit. This matters because web technologies and standards are not standing still. In fact, it's moving faster than ever and it requires a large effort to keep up. While I have all the admiration and respect in the world for the team working on KHTML and believe that given enough time there isn't anything they couldn't implement, the reality is that the amount of person-hours are limited and it is a far more sure bet that WebKit will keep pace in a relevant manner relative to the standards given the companies and communities behind it.
This affects all applications that would like to use the newer XHTML features that are becoming available.
There is also the issue of bug and feature compatibility. It is not true that every usage of WebKit is bug compatible or even feature compatible. This is because different products that use WebKit often ship with a branch or fork of WebKit that is slightly different from other branches out there. In part the differences stem from the branches coming off of mainline at different points in time (so it's an artifact of different release schedules) but also in part due to some customizations that are application-specific that get made. Still, there is greater similarity than difference and due to the number of WebKit apps and web browsers out there in daily usage, WebKit variants get more testing by web developers than our own KHTML does or likely ever will.
This is something that primarily affects usage in a web browser, such as Konqueror, however. For applications that generate their own content (e.g. KMail's email viewer), it's a non-issue. It does still come into play for applications that are doing "mash ups" using content directly ripped from sites online.
WebKit also has a number of technical tricks that have given some projects, such as Plasma, to already start using it.
First, it's canvas friendly and is easy to make at home on a QGraphicsScene. The Plasma team already did up some basic integration for gestures and zooming, but the Qt devs have recently gone even further and cooked up a really nice, mobile-ready implementation with things like "over scrolling" where you can scroll into areas of the page that haven't been rendered yet and they are "grey" until filled. That's mostly a mobile platform issue, but it shows what is not only possible but available today.
Then there is the really nice support for "mashing up" C++ (or, I suppose, Ruby/Python/etc) elements from your app with the web canvas and control element presentation and content from the app's "native" language.
There are also things like the very nice Web Inspector that comes along with WebKit for free. There are efforts underway for things like accelerating animations and effects and web slices/scraps. These are all cool things above and beyond "just" WebKit and shows that even in the Qt layers there is really interesting progress that continues to be made.
The above are all reasons why QtWebKit was the best fit choice for Plasma: we use QtScript, we are doing "mash ups" fairly regularly and we need as many of the current web features as possible. The Silk project is also relying on QtWebKit for things such as the site-specific browser, Selkie.
Release Schedule Challenges
One challenge that comes up in regards to relying on QtWebKit is whether or not KDE's release schedules and our development needs (read: feature requests) can be met by relying on a project with a different release schedule and even different feature priorities.
Features we need in a web rendering stack essentially come down to this: what does the current web dev community expect to be available in a web rendering stack (WebKit generally has the upper hand here) and what integration points into KDE technologies does the stack have? When it comes to integration points, the QtWebKit team has shown themselves to be very responsive to this and solutions have been forthcoming. It it what enabled the work done for KDE WebKit to be possible. For this reason, I don't think that features are a reasonable objection at this point.
As for release schedule timing, we have turned the art of "when will Qt get feature $FOO" into a science in KDE. I'd rather coordinate with Qt's schedule to get the desired features and performance results than have a perfectly melded schedule. Yes, it's a trade off, but the benefits outweigh the costs here.
Of course, others may have different opinions ... but we really ought to stop waffling just because there are different opinions.
WebKit came from KHTML. It is, in my mind, the next step in the KDE Web Experience odyssey. (Again, others will differ in viewpoint, I'm sure.) WebKit has "taken over the world" as much as that is possible, becoming probably the most widely deployed web stack in terms of usage in different projects. The user base is also huge. These are successes that used our own people's efforts as a springboard. We should embrace that success and make it our own again rather than be put off due to it.
To speak to the "elephant in the room": I don't want to see KHTML development cease, nor do I think it should be limited or even needs to be. However, KHTML's existence alone does not mean that KDE applications must use it if there are more appropriate alternatives. "More appropriate" is a somewhat loaded term; in my mind WebKit would need to meet the integration requirements (using technology stacks which are so foreign that they degrade integration is not a good answer). It's an unenviable position to have competing technologies to choose from, especially when they are so close to our hearts, but this is the kind of decision we are faced with.
As more KDE applications use QtWebKit, if only because it offers features and functionality that we can't expect to get elsewhere in reasonable time frames, we are faced with a poignant question: are we comfortable with having some applications using one web stack and other applications using a different one? (That is our current reality.) Should we be aiming for consistency here, using the web stack that has the most to offer, weighing integration together with features and developer resources? Or are we alright with the extra overhead of having multiple web rendering stacks required for a KDE experience?
This is a discussion that's been simmering for a couple of years now. I think it's been somewhat academic up until this point because we didn't have KDE WebKit and QtWebKit was still missing important functionality. The current state, however, is that we do have KDE WebKit and QtWebKit is ready for what we use it for in our applications. I know because I've spent time over the last year looking at how we use XHTML in our various applications, whether it's in the KDE Help Center, KMail, the application welcome screens or apps like Plasma which are a bit more dynamic in their XHTML usage. The questions are therefore no longer academic but practical.
KDE application developers should form a consensus around this issue as much as is possible. We should want KDE applications do what is best for the applications and therefore our users. I personally believe that KDE WebKit is our best option, but consensus followed by action is what will really count. This is not the easiest decision, but then again it isn't really the hardest of decisions, either. If we decide make KDE WebKit (already it is included with kdelibs) as part of our applications' evolutionary path I think we will gain enough from it in terms of features and performance to justify the efforts.
Beyond What We Could, And Recognizing What We Are Already Doing
WebKit is already an integral part of Plasma, Amarok, Selkie and Rekonq. I can only assume it's being used in even more KDE applications and I just haven't noticed it yet. Regardless of what other KDE applications do, usage of WebKit in these applications means WebKit will be making a significant impression within the KDE universe in 2010.
Using it to write Plasmoids, both via QtScript as well as directly using XHTML/JS in a WebKit container, is just one example of where it is taking us. Due to this emergence, and the question we now have in front of us regarding just how pervasively we want to use KDE WebKit in KDE applications, this will be one topic that will be a noticeable part of 2010 for us.
I'd like to close with a huge "THANK YOU" and an expression of my respect and gratitude to everyone who has worked on KHTML today or in the past. I think it's been a remarkable project from day one and remains a remarkable project right to this day. It blazed trails for F/OSS web stacks and has become insanely successful in various ways. This stands on its own, inviolable and untouched by the contents of this blog entry.
This also closes out the "Key Quests for 2010" blog entry series. I hope those who have read it have enjoyed it or at least been moved to thinking about some of the opportunities, challenges and ideas we who make up KDE are going to come across in the year ahead. I also truly hope that it inspires further discussion throughout the community and that they entries serve not as end points but as conversation starters, though provokers. None of us alone have all the answers, but together we can get pretty close. This has been key to the success of KDE.
There are so many compelling and exciting things afoot in KDE right now that 2010 is almost certainly going to be an amazing year for all of us. The 14 areas of interest I discussed in this series just scratch the surface, and mostly in areas of KDE-wide needs. There is so much more that happens at the "local" level within KDE and so many more things that are going so well that we hardly need to add to the discussions those topics already receive. That why KDE in 2010 is an experience I can't wait to be a part of along with all of you.
(This article is part of the "Key Quests for KDE in 2010" series)