Surfin’ Safari

A familiar and unpleasant sight in web applications is fragile code traversing the DOM to get to certain elements or collections of elements. Chains of getElementById("something").parent.parent are all too common, hurting both readability and flexibility. As a result, many javascript libraries have implemented functions to use the powerful CSS selector system to look up DOM nodes.

Continuing the trend of standardizing and speeding up commonly used functionality from these libraries, WebKit now has support for the new W3C Selectors API, which consists of the querySelector and querySelectorAll methods. Hopefully libraries will begin to adopt this new functionality to provide performance improvements while remaining compatible with older browsers.

Some examples of how it could be used:

  /*
   * Get all the elements with class "hot" (duplicating getElementsByClassName)
   * A common use for this is as a toggle;
   * for example, a search feature might tag results with a class
   */
  document.querySelectorAll(".hot");

  /*
   * Get the currently hovered element
   */
  document.querySelector(":hover");

  /*
   * Get every other element in the <li> with id "large"
   * This is mostly useful for doing "zebra stripe" alternating rows.
   * Once CSS3 becomes more widespread, doing this directly via CSS will be more practical
   */
  document.querySelectorAll("#large:nth-child(even)");

What would a new API like this be without benchmarks? The mootools project has conveniently created a wonderful test and benchmark suite for just this sort of functionality. A version of it that has been modified to test querySelectorAll as well as three common javascript libraries is available at http://webkit.org/perf/slickspeed/. Please note that many of the tests will only work in a build of WebKit from February 7th or later.

The new IE8 version targeting switch, announced on IEBlog and A List Apart, has been the talk of the web. Some web standards experts, like Eric Meyer and Jeffrey Zeldman see the switch in a positive light. Others, including Dean Edwards, Robert O’Callahan and Anne van Kesteren think the proposal is a bad idea.

We don’t talk much about what other browsers are doing on this blog. While we’re happy to collaborate on web standards and testing, and sometimes share a little friendly rivalry, we try to keep our focus on making the best Web browser engine we can, not on the competition. So we’re not going to give in-depth commentary on the IE team’s decision. Straddling compatibility and Web standards is a tough job requiring tough choices.

However, some have asked if other browser engines, including WebKit, would adopt a similar version switch. For example, the original announcement asks, “I, for one, hope other browser vendors join Microsoft in implementing this functionality.” I can’t make any definitive statement for all time, but such an approach does not seem like a good idea to us currently. Why, you may ask? There are a few reasons.

Mode Switches in WebKit

WebKit, like most browser engines, has a quirks mode that is triggered by certain old HTML doctypes, or lack of a doctype declaration in text/html. Documents with newer or unknown doctypes, or sent as XML, are processed in standards mode. Like Mozilla and Opera, we apply only a limited set of nonstandard behaviors in quirks mode, and otherwise fix bugs across both modes, if they do not have a specific significant impact on Web compatibility. This is in contrast to the IE approach of completely freezing old behavior in quirks mode.

We actually have a few modes besides that. A handful of doctypes trigger what is called “almost standards mode”, which is standards mode with one minor deviation, mainly affecting how images lay out in table cells; this is copied from Mozilla. In addition, we have a few rendering and DOM differences between documents served with an XML MIME type and those served with an HTML MIME type, but we are trying to reduce these over time. And finally, we have a Dashboard compatibility mode that has a few extra quirks beyond quirks mode, to handle Dashboard widgets that were coded to depend on old WebKit bugs.

Maintainability

As you can see, this is quite a few modes already. Having lots of modes raises a number of challenges for maintaining the engine.

First, the more different modes there are, the harder it is to fully test the engine. We have an aggressive approach to automated testing, and our layout tests often find critical problems before they are shipped or even checked in. Having more modes means many things need to be tested in multiple modes. So that’s more tests, more time for developers to run the test suite, and more chances of missing code coverage, especially when different modes interact.

Second, implementing mode switches hurts hackability of the code. Hackability is one of our core project goals. It’s part of the reason new contributors can dive in quickly, and enables us to rapidly develop new features, while improving performance, stability, and security.

There’s two plausible ways to add more modes. One is to make all engine changes conditional on a version flag. Another is to have a whole second copy of the layout code. Either would be a huge additional barrier to entry for developers, and would make it harder to maintain the code.

So, bottom line, we’d like to see fewer modes, not more.

Mobile-Readiness

In addition to maintainability, an important feature of the WebKit engine is the ease with which it is deployed on limited-capability devices such as mobile phones. Some of the more prominent examples include Nokia’s S60 Browser, Apple’s iPhone and iPod touch, and Google’s Android platform. These and other products all include a full-powered version of WebKit, no compromises.

However, having more mode switches cuts against this. The extra code (possibly whole extra copies of the engine, at the very least a whole lot of extra if statements) would be a significant burden on mobile devices. It’s not very well aligned with our mission of staying lean and mean.

Commitment to Standards and Interoperability

Yet another reason we feel more mode switches are not a good idea for WebKit is our commitment to Web standards, and to interoperability with other browsers. We strongly believe that Web standards are the path forward for interoperability, and we work closely with Web standards groups and other browser vendors to align behavior.

Part of this commitment is delivering standards-compliant behavior out of the box. We don’t ask you to set a special preference, or to add extra markup to your web page, or anything else beyond the long established standards mode switch. That means WebKit can truly pass standards-based tests like Acid2 and someday the forthcoming Acid3, and we’ll work more like other standards-based browsers over time. In general, web developers are happy to get automatic ever-advancing standards support from our engine, and indeed our support for advanced CSS3 properties has unleashed a wave of creativity in iPhone web apps.

Reducing Engine Fragmentation

Another key reason to avoid more modes is to reduce the number of different compatibility profiles that web content authors have to deal with. With many different vendors shipping WebKit-based products, we rely a lot on the fact that uptake of WebKit-based browsers is really fast. Already many web developers are focusing primarily on Safari 3 and not Safari 2, because in only a few months the majority of users have upgraded.

But locking in compatibility would mean you have to think about the compatibility profiles of old browsers a lot longer. And no one wants to think about the state of the engine in Safari 2 - I sure don’t! We made thousands of fixes and improvements and those fixes deserve to stick.

We Don’t Really Need It

Finally, while we sympathize with the tough road that the IE team has to travel to achieve a high degree of standards compliance, we haven’t really experienced the same problem. The IE team has mentioned severe negative feedback on the IE7 release, due to sites expecting standards behavior from most browsers, but IE6 bugs from IE.

But WebKit already has a high degree of standards compliance. And we are not in the enviable but tough position of being the most widely used browser. The fixes we do for standards compliance rarely cause widespread destruction, and when they do, it’s often a sign that the standards themselves may need revision. We do not get complaints from web content authors about their sites breaking, on the contrary we get a lot of praise for each version of the engine handling web sites better.

Conclusion

So, in conclusion, we don’t see a great need to implement version targeting in Safari. We think maintaining multiple versions of the engine would have many downsides for us and little upside. The IE team is, of course, under different constraints and free to make their own choices.

getElementsByClassName is one of the more common functions requested by JavaScript programmers (and added by JavaScript libraries); it works along the same lines as getElementsByTagName and getElementById in looking up elements of a web page by their properties. In fact, it’s so common that in the new in-progress HTML5 specification it’s been added to the official DOM API. Last week WebKit joined upcoming versions of Firefox and Opera in supporting this new feature.

The advantages of a native implementation are clear:

• No additional JavaScript library files required
• Clearly specified and consistent behavior
• Blindingly fast

How fast? Let’s have a look at WebKit’s shiny new implementation. For testing purposes I wrote a simple benchmark allowing comparison between three different methods for getting elements by their class names. The first is the new native getElementsByClassName, and the last two are both from prototype.js; one uses XPath, and the other is a straight JavaScript/DOM implementation.

The results speak for themselves. Web applications that do a lot of class lookups should see noticeable speed improvements when run with any of the native implementations, and existing JavaScript libraries can fill in for older or less advanced browsers. John Resig has run a different benchmark of the same functionality in Firefox 3 and observed a similar native vs. JavaScript/DOM speedup ratio.

Testing Methodology:
Tests were run three times, then averaged. The page was reloaded between each run. The browser used was Safari 3 with WebKit r28911. The hardware was a 2GHz Apple MacBook with 3GB of RAM running Mac OS X 10.5.1. The XPath and JS/DOM functions are from Prototype 1.5.1.

A New JavaScript Benchmark From the WebKit Team

Here in WebKit-land, we strive for great performance and we love to make things faster. When doing performance work, it’s critical to be able to measure how fast you are at any given time and track changes. And it’s important to make sure your metric reflects realistic use cases. None of the existing JavaScript benchmarks were exactly suited to our needs (more on that below), so we decided to make our own.

We’re widely announcing this benchmark today because we’d like to share with other browser-hosted and standalone JavaScript engines. And we’d like to have input from JavaScript experts on the usefulness and validity of the tests. In that spirit of cooperation, we’re not going to post competitive numbers or even comparisons to older Safari/WebKit versions for now (although I can tell you that the shipping version of Safari 3 is not the fastest JS engine we tested).

Try It Out!

But people like playing with these benchmarks. So I’m sure a lot of you would like to try your luck and test your browser. If you’d like to post your results in the comments, please mention what browser, what version, and what hardware and OS you’re running on. Make sure to quit extraneous apps and avoid jiggling your mouse for the minute or two that it runs. Have fun!

The Gory Details

There are a lot of JavaScript benchmarks out there already: Celtic Kane’s JavaScript speed test, the JavaScript processing test from iBench, Jason Orendorff’s JavaScript speed tests, John Resig’s tests, and others. But none of these were quite what we needed to measure improve real-world JavaScript performance.

So we made our own. Why bother? Well, we think our benchmark has a combination of useful properties that we didn’t see in any existing test:

• It’s based on real code that does interesting things; both things that the web apps of today are doing, and more advanced code of the sorts we can expect as web apps become more advanced. Very few of the tests could be classed as microbenchmarks.
• It’s balanced between different aspects of the JavaScript language — not dominated by just a small handful of different things. In fact, we collected test cases from all over the web, including from other benchmarks. But at the same time, we avoided DOM tests and stuck to the core JavaScript language itself.
• It’s super easy to run in the browser or from the command line, so you can test both pure engine performance, and the results you actually get in the browser.
• We included statistical analysis so you can see how stable the results you’re getting really are.

Incidentally, we’ve been doing a lot of work on JavaScript performance lately. If you’re interested in helping out, stop by the webkit-dev@webkit.org mailing list, or the #webkit IRC channel on chat.freenode.net and say hi. Our engine is highly hackable so it’s easier than you think to get started.

I’m happy to announce that Holger Freyther is now a WebKit reviewer. Since arriving on the WebKit scene in early ‘07 he has proven himself to be a consistently solid contributer. After valuable work cleaning up the GTK+/Qt build systems and the GTK+ public API he continues to help fill in other missing pieces of the GTK+ and Qt ports. All the while he’s shown great judgement and collaboration with the WebKit community as a whole. It’s no wonder the nomination for him to become a reviewer - the first through our new committer and reviewer policy - was quickly confirmed.

Please join me in congratulating Holger!

As Maciej said, web developer tools are a big new feature of WebKit 3. Since we first introduced the new Web Inspector back in June, Tim Hatcher (xenon in #webkit) has been spearheading the effort to make the Web Inspector an even better tool for web developers, and I wanted to give an update on the progress we’ve made so far. If you’ve never used the Inspector before, you should follow the instructions to enable the Web Inspector on the WebKit wiki.

New Features

Inline CSS Editing

This is the biggest new feature of the Inspector. You can now edit CSS styles simply by double-clicking them in the Inspector’s Styles sidebar. This is really handy for tweaking the look of your site live in the browser.

Support for Downloadable Fonts

When you visit a site that uses downloadable fonts via @font-face rules, the Inspector will show you all the fonts downloaded by WebKit in the Resources sidebar. Each font has a small icon preview in the sidebar and a more complete preview when you select it.

Database Browser

WebKit now supports the HTML5 SQL storage API, and the Inspector has full support for this new feature. You can execute SQL queries right in the Inspector and see the results live, or browse through all the databases and tables a website uses.

Support for New CSS Properties

The Inspector shows the new CSS transform and animation properties in its Styles sidebar. You can even trigger animations on the fly by using the Inspector’s inline CSS editing!

Multi-Platform Support

The Inspector was designed from the beginning to be easily implementable on many platforms, and has worked on both Mac OS X and Microsoft Windows from the very beginning. Recently, Holger Freyther has stepped up and implemented the Web Inspector on Qt.

Usability Improvements

In addition to all these big features, we’ve spent some time fixing some of the little things that make the Inspector that much easier to use. The list of usability improvements includes resizable sidebars, resizable search area, size-to-fit DOM breadcrumbs, and better selection and copying behavior. One of my favorite features in this area is that when you Copy while a node is selected in the DOM view, the serialized source for that node and its children are put on the clipboard. This makes it incredibly easy to take a portion of a live website (complete with any modifications that have been made to the DOM) and modify it in a text editor.

You can try out all these new features today by running a nightly WebKit build.

Future Work

There’s still a lot of work to be done on the Inspector, and we’d love to have your help. Most of the Web Inspector is written in HTML, JavaScript, and CSS, so it’s easy to get started making changes and improvements. There are some really interesting tasks in the list of Web Inspector bugs and enhancements, and the WebKit contributors in the #webkit chat room are pretty much always available to provide help and advice.

Surfin’ Safari has always been a great place to get information about WebKit, from descriptions of the many new features being added to technical discussions of engine internals to announcements of WebKit being used in entirely new places. But the web is a big place, and we want to make it easier to find the many great articles WebKit contributors are writing every day on their own blogs. So we’ve recently set up Planet WebKit, your one-stop-shop for information about WebKit development and its growing uses in the world, straight from the developers’ mouths. Special thanks to Matt Lilek and Tim Hatcher for coming up with a great look for Planet WebKit. Bookmark the page or subscribe to the feed and start reading!

Historically, new WebKit committers and reviewers have been chosen through an internal Apple process. I am pleased to announce a new open, community-based Committer and Reviewer Policy.

Some highlights of the new policy:

• New committers and reviewers will be chosen by the existing project reviewers.
• The policy treats everyone equally, regardless of corporate affiliation.
• There is a clear statement of criteria to be considered as potential a committer or reviewer.

This new policy should address many of the concerns raised by non-Apple contributors to the project and help sustain WebKit’s amazing industry-wide growth.

Lately we’ve been talking about a lot of great new features in the latest development trunk of WebKit - features like web fonts, client-side database storage, CSS transforms and CSS animation. These features will likely make it to an official release someday. But I’d like to take a step back and talk about some older features, namely all the great stuff in our recent stable release.

Apple recently released Mac OS X 10.5 “Leopard”, including Safari 3. The latest Safari is also included in Mac OS X 10.4.11, the latest update to Tiger. A corresponding version is available as the latest Safari for Windows Beta, including the new features and lots of stability and usability improvements.

Apple’s site can tell you a lot about the new end-user features of Safari 3. But a lot of the goodness is on the inside, in the WebKit engine that powers Safari. Here’s a list of ten of the most exciting engine enhancements since the Safari 2 version of WebKit, with lots of details and demos. These features are all included in the WebKit that comes with Safari 3 - you don’t have to download nightlies or anything else to get them.

1. Enhanced Rich Text Editing

As you browse the web with a WebKit 3 based browser, you will get a complete and functional rich text editing experience on the new read-write web. Here’s a sweet demo of our improved editing support, just click the text and editing controls appear.

Specifically, we have worked together with developers of RTE libraries and applications to improve compatibility. WebKit 3 fixes many bugs, and supports additional text editing features like links and lists. We now have support from web applications like WordPress, Google Docs, GMail, Blogger, and many more. We’ve also improved editing to support libraries like TinyMCE and FCKeditor. We expect even more web apps and toolkits to add support over time.

2. Faster JavaScript and DOM

We have greatly improved the speed of JavaScript and DOM operations, both critical to the performance of today’s rich web applications. You can see this on a number of benchmarks. To gather the results below, I tested on a MacBook Pro (2 GHz Core Duo, 1 GB RAM). For the WebKit 2 results, I used Safari 2.0.4 on Mac OS X 10.4 Tiger. For the WebKit 3 results, I used Safari 3.0.4 on Mac OS X 10.5 Leopard.

• i-Bench JavaScript Processing - The primary benchmark that Apple marketing has used is the JavaScript i-Bench. While you can download it yourself, it’s a bit of a pain to set up. Most of the other benchmarks listed below are easier to run yourself, but are not as realistic and comprehensive in their coverage.
  WebKit 2 - 1.99 sec
  WebKit 3 - 0.87 sec
  WebKit 3 is 2.3 times as fast!
• Celtic Kane Javascript Speed Test 2007 - This popular benchmark is easy to try in the browser and covers a variety of JavaScript and DOM processing tasks.
  WebKit 2 - 1276 ms
  WebKit 3 - 624 ms
  WebKit 3 is 2 times as fast!
• pentestmonkey MD5 test - This test times various cryptographic checksums coded in pure JavaScript. Run it here.. I’m reporting only the MD5 numbers - the other changes are similar.
  WebKit 2 - 8.352 sec
  WebKit 3 - 3.794 sec
  WebKit 3 is 2.2 times as fast!
• JavaScript Raytracer - The full mode of this JavaScript Ray Tracer is a test of many parts of the browser including JavaScript, DOM and layout.
  WebKit 2 - 853.594 sec
  WebKit 3 - 48.48 sec
  WebKit 3 is 17.6 times as fast!

If you try other JavaScript and DOM benchmarks on the web, you’ll see similar results - speedups of 2x or more. These are speedups you will really feel on advanced web applications.

3. Faster Page Loading

WebKit 3 also offers significantly improved raw page loading speed. Unfortunately it’s hard to find good benchmarks in this area. The best we know of is the HTML i-Bench which is a pain for the casual user to set up, but which is based on real web content.

Some have argued that page loading benchmarks are unfair because browsers dispatch the load before painting, and Safari will sometimes even do it before the first layout. But the HTML i-Bench is one of the few tests to factor this out - it forces a layout and scrolls to ensure a paint. Here’s the numbers:

WebKit 2 - 2.95 sec
WebKit 3 - 2.06 sec
WebKit 3 is 1.4 times as fast!

In addition, independent researchers confirm that Safari 3’s page loading is really fast.

4. SVG

WebKit 3 features a major new technology - SVG (Scalable Vector Graphics). SVG is an XML markup language for graphics that allows rich interaction and which can be mixed directly with XHTML. Here’s some whizzy demos:

• Dock-style magnify effect.
• Picture of a butterfly.
• An interactive population pyramid chart.
• Interactive demo of mouth shape during speech.
• Crashdown game - click groups of same-colored blocks to get points.
• Pie charts using the Dojo charting engine.

We haven’t profiled and optimized SVG quite as much as the rest of the engine, but early tests seem to indicate that it already has blazing performance. Look for this exciting new technology to see even more use on the web over time, now that it is supported by WebKit, the Gecko engine inside Firefox, and the Presto engine inside Opera.

5. XPath

Another major brand new technology in WebKit 3 is XPath, the XML Path Language. XPath is a W3C standard query language that lets web developers efficiently find particular elements in the document. Since XPath is a programming language, it’s hard to show a pretty demo, but this tutorial goes in depth and has a few examples. XPath is used in AJAX toolkits like TIBCO General Interface, and can be used by CSS query engines for improved performance, as in dojo.query.

6. New and Improved XML Technologies

In addition to the big new features of XPath and XVG, we have lots of new and improved XML technologies:

• The XSLTProcessor JavaScript API for XSLT, and many XSLT fixes and improvements including support for external entities.
• The DOMParser API.
• The XMLSerializer API.
• Incremental rendering support for XML.
• Proper support for named character references in XHTML.
• Much more complete and compatible XMLHttpRequest, including support for event listeners, incremental updates for persistent server connections, parsing of more XML MIME types, support for more HTTP methods.

7. Styleable Form Controls

WebKit 3 introduces the ability to customize the look of form controls with CSS. We still use standard looking native form when no custom styles are applied, but we have the ability to customize the look to better support sites with a strong visual identity. Here’s a few simple examples:

Button with bold text

Here’s some older, more advanced examples for styleable text fields. On other sites, you can find demo pages for styling all sorts of form controls.

8. Advanced CSS Styling

We have added many advanced CSS features that let content authors make better-looking sites with less effort. These include experimental WebKit features or early implementations of CSS3. Here’s a quick demo of some of them (you’ll only see the fancy stuff with a WebKit 3 based browser):

In addition to the features shown here, many more CSS 2.1, CSS 3, and WebKit experimental features are included. We support CSS Media queries, and lots of background improvements like background-origin and background-clip, multiple backgrounds (since Safari 2, but still only supported by WebKit), box-sizing and more. Another cool new feature is border-image, which lets you make resizable control backgrounds using a single image - there’s some demos in this sample code for the iPhone in the buttons section.

See this Safari CSS reference document for a complete list.

9. Reduced Memory Use

The latest stable WebKit has enabled significantly reduced memory use, compared to the Safari 2 version. We have made many kinds of improvements. Pages containing large amounts of text are stored more efficiently. JavaScript code generates smaller data structures. And most significant of all, we’ve revamped the way we handle the memory cache. The cache is now much better at holding the data that’s truly critical for faster page loading, but less of the data that can easily be recomputed, like decoded image data.

Memory use is something that is notoriously hard to measure. The browser has many caches, and many sites on the live web server. The best way I could find to measure repeatably was by looking at memory use after running through the HTML i-Bench, but your results on other sites may vary. Here is what I saw:

WebKit 2 - 26.7M RPRVT memory
WebKit 3 - 23M RPRVT memory
WebKit 3 uses 14% less memory!

Improving memory use will remain an important focus for future releases.

10. Web Developer Tools

One of the best WebKit improvements is the availability of Web Developer tools, the Web Inspector and the Drosera JavaScript debugger. I can’t really describe these better than the original blog posts, so here’s some screenshots and links to the original posts:

Web Inspector:

Drosera:

Conclusion

So that’s it, ten huge new features in WebKit 3. Grab Mac OS X Leopard, the 10.4.11 update to Mac OS X Tiger, Safari 3.0.4 Beta for Windows, or your favorite other WebKit-based browser to check them out for yourself, along with thousands of smaller features and bug fixes.

Google’s Android announcement (see post below) has led to a new round of stories about WebKit in the blogosphere. Om Malik writes about The Amazing Rise of WebKit Mobile. Jason Delport echoes his sentiment in a piece titled The Rise of the WebKit Browser. Ajaxian refers to Another WebKit win with Android. And John Gordon rescinds his former WebKit pessimism to admit, Safari: Ok, you win.

It’s worth noting that WebKit porting efforts are heating up. In the mobile space we already have WebKit in two product lines: Apple’s iPhone and Nokia’s S60 platform. In addition, the Qt port will be included in Qt 4.4, including the Qtopia mobile platform.

The Gtk+ port has been used to build mobile browsers for the Maemo and OpenMoko platforms. It is also available experimentally as a backend for GNOME’s Epiphany web browser.

Other ports and products in various stages of progress include the Origyn Web Browser, a sort of meta-port for various consumer electronics platforms, Wake3’s port to Windows CE, Adobe AIR, the Haiku operating system, wxWidgets and more.

And of course there are the many browsers and other applications using WebKit.

It’s exciting to see WebKit going more and more places, and get acknowledgement in the press for the community’s success in building a world class browser engine.