How WebKit Achieved a 100/100 Acid3 Score in 2008

In March 2008, the WebKit development team made browser history by achieving a perfect 100/100 score on the newly released Acid3 web standards test using development builds of Apple’s Safari browser. This article outlines how the team reached this milestone through a rapid, public engineering sprint that resolved dozens of complex bugs across the Document Object Model (DOM), ECMAScript (JavaScript), CSS3, and Scalable Vector Graphics (SVG) specifications, ultimately culminating in a fully compliant, high-performance rendering engine by September 2008.

Understanding the Acid3 Challenge

Released on March 3, 2008, by Ian Hickson of the Web Standards Project, the Acid3 test was designed to push browsers to their limits regarding Web 2.0 technologies. Unlike Acid2, which primarily tested HTML and CSS rendering, Acid3 consisted of 100 individual subtests divided into six groups called "buckets."

When the test was officially announced, WebKit nightly builds scored roughly 87/100. To reach 100/100, the browser had to not only render a reference image pixel-for-pixel, but also execute complex JavaScript and DOM manipulations without errors.

The Master Bug and Open-Source Coordination

To conquer the remaining subtests, WebKit lead Maciej Stachowiak and the core engineering team utilized a highly organized, transparent approach.

  1. The Metabug: The team created a master tracking bug in the WebKit Bugzilla database. Every failed subtest in Acid3 was isolated, reduced to a minimal test case, and assigned its own individual bug report linked to the master bug.
  2. Real-Time Collaboration: Developers coordinated in real-time via the #webkit IRC channel. As soon as Ian Hickson finalized the test, WebKit contributors—including Apple engineers and independent open-source developers—began claiming specific bugs to fix.
  3. Rapid Iteration: Because WebKit utilized automated nightly builds, anyone could download the latest version of Safari every few hours to watch the score climb in real-time.

Conquering the Technical Hurdles

The WebKit team had to implement entirely new features and fix obscure edge cases across four primary areas of the browser engine to pass all 100 subtests.

1. DOM2 Traversal and Range

The first bucket of Acid3 heavily tested DOM Level 2 Traversal and Range specifications. WebKit already had basic support, but Acid3 intentionally triggered edge cases, such as modifying the DOM tree while an iterator was actively traversing it. The team rewrote portions of WebKit's node iteration and range handling code to strictly adhere to W3C specifications under these extreme conditions.

2. ECMAScript (JavaScript) Edge Cases

Acid3 tested the dark corners of the ECMAScript specification. To pass these tests, developers working on JavaScriptCore (WebKit’s JavaScript engine) had to fix bugs related to:

  • Unicode zero-width characters in identifiers.
  • Strict compliance in Array methods and regular expression quantifiers.
  • Proper exception throwing and scoping rules within try-catch blocks.

3. SVG Fonts and SMIL Animation

One of WebKit's biggest hurdles was the fifth bucket, which tested Scalable Vector Graphics (SVG) and Synchronized Multimedia Integration Language (SMIL). At the start of 2008, WebKit had an incomplete implementation of these standards. Within weeks, the team implemented support for SVG Fonts, complex path manipulations, and basic SMIL animation timing so the browser could natively parse and render vector data manipulated by JavaScript.

4. CSS3 Selectors and Web Fonts

To pass the visual rendering aspect of the test, WebKit engineers finalized support for advanced CSS3 selectors (such as :nth-child() and :last-child), CSS3 Media Queries, and downloadable @font-face web fonts. They also resolved subtle layout bugs involving negative margins, white-space collapsing, and z-index layering.

Winning the Race on March 26, 2008

After just over three weeks of relentless patching, the WebKit team resolved the final rendering bug—an issue related to SVG text path rendering. On March 26, 2008, WebKit Revision 31342 officially scored 100/100 and rendered the test identically to the reference image.

While the Opera browser team announced a 100/100 score using an internal lab build earlier that same day, WebKit was the first to provide a publicly downloadable build that anyone could use to verify the 100/100 score.

The Final Requirement: Smoothness

Scoring 100/100 was only part of the Acid3 specification. For a browser to officially pass the test, the animation of the score counting up from 0 to 100 had to be completely smooth, meaning no single subtest could take longer than 33 milliseconds to execute on reference hardware.

In March 2008, a few of WebKit's subtests still paused briefly during execution. Over the summer of 2008, the WebKit team introduced SquirrelFish, a brand-new bytecode interpreter for JavaScriptCore that drastically increased execution speed. Combined with further DOM optimizations, WebKit eliminated all rendering lag. In September 2008, Safari development builds officially met the strict timing requirements, making WebKit the first browser engine to fully and unconditionally pass the Acid3 test.