Re: WebKit and GNOME

[David Bolter <david bolter utoronto ca>]

Hi Maciej,

Thanks very much for providing this information. I have a brief comment
about your accessibility section below:

Maciej Stachowiak wrote:
> Hello GNOMErs,
>
> Some of you may remember me from back in my GNOME development days.  
> These days I work on WebKit, an open source Web content engine. I've  
> heard that WebKit is of interest to the GNOME/Gtk community, and I  
> have followed the Gtk+ port in WebKit trunk closely. Since WebKit/Gtk+  
> is now under consideration as an external dependency for GNOME, I  
> thought I'd share some information about WebKit from my perspective.
>
> I think the GNOME project has to decide for itself, so I'm going to  
> try to avoid excessive marketing, but obviously it is impossible for  
> me to completely avoid bias.
>
> One thing to consider is whether WebKit's goals are aligned with  
> GNOME's requirements for a Web content engine. I don't think I can  
> describe them better than our statement of project goals: <http://webkit.org/projects/goals.html 
>  >.
>
> I think WebKit has a couple of strengths from the perspective of  
> desktop integration. The WebKit project sees itself as a technology  
> provider, not an end-user product. For this reason, we put a high  
> priority on making the engine usable for a wide variety of  
> applications, and on enabling tight integration with different  
> environments. As a result of this focus we have:
>
> 1) Easy to use platform-native APIs on each target platform. The Mac  
> OS X port's Objective-C/Cocoa API has been widely praised, and the Qt  
> and Gtk+ ports provide their own native-feeling APIs. Here is a  
> partial (and somewhat out of date) list of the many applications using  
> WebKit: <http://trac.webkit.org/projects/webkit/wiki/Applications%20using%20WebKit 
>  >.
>
> 2) Extensive use of platform-native APIs and services. Our porting  
> layer is designed to build on top of a capable underlying operating  
> environment, and to make use of its services. This reduces code  
> footprint (no need to duplicate code that is already in platform  
> libraries) and enables tight integration.
>
> More generally, we let platform owners decide on the strategic  
> direction for their port's API and platform integration. Apple owns  
> the Mac port and generally takes the lead in deciding what the API  
> looks like on Mac OS X, but the Qt and Gtk+ ports are designed by  
> TrollTech and by Gtk+-focused WebKit developers respectively.
>
> Besides these strengths from the point of view of integration, I think  
> WebKit has a number of other strengths:
>
> 1) Web standards compliance. WebKit has a high degree of Web standards  
> compliance. We not only get the basics right but are often the first  
> to pass standards compliance torture tests like Acid2, and recently  
> Acid3: <http://webkit.org/blog/173/webkit-achieves-acid3-100100-in-public-build/ 
>  >. We have also been pushing ahead with early support for forthcoming  
> new standards like CSS3 and HTML5.
>
> 2) Performance. Our performance rocks. You can find lots of benchmarks  
> out there for speed and memory and WebKit isn't the winner of every  
> single one, but you'll find that we're often first and rarely last.  
> With memory use the story is somewhat more complicated. Our memory use  
> depends partly on the platform integration layer (images in the memory  
> cache are a large component) and partly on low-level bits of the  
> custom allocator. It is much better on Mac OS X than Windows, because  
> our custom allocator supports returning memory to the system. I  
> believe this code will work on other Unix-like platforms (such as  
> Linux), but I haven't personally tested. We're hoping to make it work  
> on Windows as well. In all fairness I have to say that other engines  
> such as Gecko (from Mozilla) and Presto (from Opera) are also quite  
> good in many performance metrics, especially with recent improvements.  
> In addition to browser performance, we've also done optimization  
> specifically for mail and instant messaging clients, and RSS readers.  
> One result of this is a scalable memory cache, so that WebKit in IM  
> clients uses much less memory than in a primary web browser.
>
> 3) Web compatibility. Web standards are nice and all, but, at least in  
> the browser, the bottom line for users is whether they can use the  
> sites they want to. Realistically, a lot of this depends on market  
> share. Internet Explorer and Firefox often have an edge simply because  
> Web developers are more likely to test in those browsers first.  
> However, increasingly Web developers are testing in Safari early, or  
> even developing in Safari first. Safari's growing market share, the  
> iPhone, and the popularity of WebKit as a browser engine on mobile  
> platforms are all giving major web developers more incentive to test  
> with us. In addition, we have done huge amounts of compatibility work.  
> In the span from Safari 2 to Safari 3, we fixed thousands of web  
> compatibility bugs and in particular made huge strides with rich text  
> editing (a longstanding problem area).
>
> 4) Hackability. I think our greatest strength is the hackability of  
> our code. Although a Web content engine is intrinsically pretty  
> complicated, we put a huge focus on simplicity and understandability,  
> both in initial development and constant aggressive code cleanup.  
> This, combined with our extensive regression test suite, allows us to  
> make progress very quickly, and makes it easy to customize WebKit for  
> particular applications as needed.
>
>
> To be fair, I think there are also weaknesses that need to be  
> addressed in WebKit in general, or in the Gtk+ port in particular:
>
> 1) BuildBot and regression test integration. The WebKit/Gtk+ port is  
> not yet set up to run our regression test suite. We think having this  
> set up is important to ensure that the rapid pace of WebKit  
> development doesn't constantly break the Gtk+ port, and that the Gtk+- 
> specific parts are working as expected. This shouldn't be too much  
> work to set up, as there are Mac, Windows and Qt versions of the  
> regression test tool already.
>
> 2) API completeness. Some advanced parts, like a GObject API to the  
> DOM, remain to be done.
>
> 3) Linux/Gtk-specific performance tuning. Most WebKit performance work  
> has been done on Mac or Windows, probably running speed tests,  
> profilers and memory tools on the Gtk port would find platform- 
> specific areas that can be improved.
>
> 4) Accessibility. This is only implemented in the Mac port currently.  
> We are moving the core accessibility code to be cross-platform, which  
> should make it fairly straightforward to hook it up to ATK or other  
> accessibility APIs. Sometimes ARIA is mentioned in the context of  
> accessibility - this is an interesting technology for future web apps,  
> but I believe basic accessibility integration for web content is a  
> higher priority.
>   

This wording "Sometimes ARIA is mentioned in the context of
accessibility - this is an interesting technology for future web apps"
doesn't seem quite right to me. ARIA enabled browsers such as Firefox
provide access to ARIA enabled DHTML applications today. Opera and IE8
are adding support today. Google is putting ARIA into its web applications.

I do however agree that addressing the cross platform accessibility
strategy in WebKit should come first and wish WebKit the best in this
endeavor.

cheers,
David

> I'm also happy to answer technical questions about WebKit, or what our  
> development process is like. I will defer to the WebKit/Gtk+ crew for  
> Gtk-port-specific questions, however.
>
>
> Regards,
> Maciej
>
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>