Mozilla Open Source

Chromium’s WebKit Fork Is No More

This is very cool news for both WebKit sand Chromium. Chromium will no longer use a forked version of WebKit. This will mean more contributions directly to WebKit and a more current Chromium.

I wish all browser vendors could agree and sync engines a bit more so that Safari/Chrome would ship the same version of WebKit rather than stagger based on their own release schedule. Same for Mozilla/Flock etc. While very difficult in many respects it would make it much easier on web developers to have less products out there to test against. I think it’s unlikely to happen, but that doesn’t mean it wouldn’t be convenient. Some Web Developer bias speaking here.

[Via: Tony Chang]

6 replies on “Chromium’s WebKit Fork Is No More”

I’m having a hard time believing any significant number of web developers bother testing with Flock.

@Me: Quite a few do, especially social media sites. Even more still test with Netscape. I’ve even heard of Camino which I think has less marketshare than any (mostly sites with a higher than normal percentage of Mac users).

Don’t forget that WebKit is a fork of Khtml, Would be nice if those two also merged …

Have you noticed the OSS & closed source partnership? The former aimed at general public and the latter at corporate users. Competitors? Firefox and IE for general public and corporate users respectively.

The problem with agreeing on version numbers is that the companies have to have, at the minimum, similar release timeframes and similar release goals/requirements.

In the case of Google Chrome versus Safari, that pretty clearly is not true. Safari so far has shipped a relatively small number of releases with large changes between them (e.g. Safari 3 to Safari 4). Google Chrome, especially on the “high-frequency” Dev/Beta channels, ships a large number of releases with much smaller changes between them. Yet those changes do include changes to WebKit.

As a Chromium developer, I’m convinced we’d be unwilling to avoid shipping WebKit changes for a year or two (or whatever the Safari release cycle is), and I strongly doubt Apple wishes to shift to a fast release-cycle, at least right at the moment.

I think the right answer is that web developers have to treat browsers as being based on engines that improve over time, the way they really do under the hood. Test for objects and capabilities where possible. Instead of testing for Safari 3 or Chrome 1, test for WebKit 528, or whatever. Chromium and Google Chrome releases make precise WebKit revisions available, so it’s possible to test for WebKit 530.2 if you know that’s the precise version that fixed your layout bug.

@Peter Kasting: I completely agree in almost every regard.

I know it’s not likely or even practical due to differences in release cycles… just wishing it out loud.

The issue is really about QA more than feature sets. It’s not a matter of “Chrome supports _________ Safari doesn’t”. It’s more about “Chrome has a bug in ______ while Safari has a bug in ________”. It’s the funny rendering quirks that every browser has, rather than features missing. Those are the things that waste the most time. It’s easy to base your code on the common subset of features that your target browsers support. It’s harder to deal with the inevitable quirky things that appear when your doing something complicated enough. You can’t really test for objects and capabilities in this situation. You end up looking for workarounds either in design/spec variation or by modifying code more than anything else.

Leave a Reply

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