We added the ElementTimeControl interface that is part of the SVG Animation specification. This completes Acid3 test 75 and got us up to 97/100. Three to go!
WebKit was still failing on test 2 of Acid3. That’s a NodeIterator test. The problem was a simple one: While NodeIterator objects were rigged to update themselves when nodes are removed from the document, there were a couple of edge cases that weren’t handled quite right. I tried to fix this about a month ago, but got confused. This time I was able to keep my head straight and it took me less than an hour to fix the bug.
We’re passing 96/100 tests now. There are only 4 points to go to get to 100 points. There are also a few loose ends that don’t cost a point and also some reports of a few failures that some see on their computers, but don’t affect most computers.
We’re closing in on 100%!
The version of WebKit that ships with Safari 3.1 on Windows uses CoreGraphics antialiasing for text. The latest WebKit in nightly builds has made good progress on a GDI text rendering mode (i.e., the text rendering matches your OS look/settings). We encourage Windows testers to try out GDI text rendering and file bugs that you find at http://bugs.webkit.org/.
To enable GDI text rendering, you will need to hand edit your preferences file, as there is no visible UI option in Safari 3.1 for this. You will need to set WebKit’s “WebKitFontSmoothingType” preference to a value of “4″.
The preferences file on Windows XP is:
C:\Documents and Settings\<username>\Application Data\Apple Computer\Safari\WebKitPreferences.plist
On Vista, it is:
C:\Users\<username>\AppData\Roaming\Apple Computer\Safari\WebKitPreferences.plist
The values that are listed in Safari’s UI for this preference map to the numbers 0-3.
Note that while you can turn on GDI text rendering in the WebKit that ships with Safari 3.1, most advanced text features will not work. These include stroking and filling text, most advanced text features in SVG, shadows, partially transparent text (rgba/hsla) and text inside a transparency layer (opacity). All of these features should work now in the latest nightlies.
If you have changed the setting in Safari you may have to edit that preference file. It can be found at:
%APPDATA%\Apple Computer\Safari\Preferences\com.apple.Safari.plist
It is well understood that page loading speed in a web browser is limited by the available connection bandwidth. However, it turns out bandwidth is not the only limiting factor and in many cases it is not even the most important one.
The graph above shows the time it took to fully load the Wall Street Journal front page (chosen for its complexity which well represents many modern web sites) with a recent WebKit. Browser caches were cleared before each page load. The Mac OS X dummynet facility was used to simulate various network conditions by introducing packet latency and capping the available bandwidth. Since the testing was done against a live web site the actual connection latency was a factor as well (ping time to wsj.com was ~75ms).
From the figure it is clear that while available bandwidth is a significant factor, so is the connection latency. Introducing just 50ms of additional latency doubled the page loading time in the high bandwidth case (from ~3200ms to ~6300ms).
Latency is a significant real world problem. Wireless networking technologies often have inherently high latencies. Packet loss and retransmits due to interference makes the situation worse. Geographical distance introduces latency. Just the roundtrip delay between US East and West Coast is somewhere around 70ms. Loaded web servers may not respond immediately.
Why does latency have such a huge impact on page loading speed? After all, to load a page completely a web browser just needs to fetch the page source and all the associated resources. The browser makes multiple connections to servers and tries to load as many resources in parallel as possible. Why would it matter much if it takes slightly longer to start loading an individual resource? Other resources should be loading during that time and the available bandwidth should still get fully utilized.
It turns out that figuring out “all the associated resources” is the hard part of the problem. The browser does not know what resources it should load until it has completely parsed the document. When the browser first receives the HTML text of the document it feeds it to the parser. The parser builds a DOM tree out of the document. When the browser sees an element like <img> that references an external resource, it requests that resources from the network.
Problems start when a document contains references to external scripts. Any script can call document.write(). Parsing can’t proceed before the script is fully loaded and executed and any document.write() output has been inserted into the document text. Since parsing is not proceeding while the script is being loaded no further requests for other resources are made either. This quickly leads to a situation where the script is the only resource loading and connection parallelism does not get exploited at all. A series of script tags essentially loads serially, hugely amplifying the effect of latency.
The situation is made worse by scripts that load additional resources. Since those resources are not known before the script is executed it is critical to load scripts as quickly as possible. The worst case is a script that load more scripts (by using document.write() to write <script> tags), a common pattern in Javascript frameworks and ad scripts.
The latest WebKit nightlies contain some new optimizations to reduce the impact of network latency. When script loading halts the main parser, we start up a side parser that goes through the rest of the HTML source to find more resources to load. We also prioritize resources so that scripts and stylesheets load before images. The overall effect is that we are now able to load more resources in parallel with scripts, including other scripts.
You can see from the graphs above that these optimizations significantly reduce the impact of network latency and generally improve page loading speed. For example with 50ms of simulated latency and no bandwidth limit, the overall page loading time was 2.8s faster (6.3s to 3.5s). With bandwidth capped to 512kbit/s the improvement was 5.9s (23.8s to 17.9s).
As of revision 31231, WebKit passes Acid3 subtests 23 (bug) and 25 (bug). That brings our score up to 95/100 — an A+! We fixed our parsing of qualified names to match the DOM Level 3 Core specification and now correctly throw NAMESPACE_ERR and INVALID_CHARACTER_ERR exceptions for invalid calls like:
document.createElementNS(null, "foo::bar") or
document.implementation.createDocumentType(":bar", null, null).
Behold the glory:
Update: The latest WebKit nightly build now includes the fixes for these two Acid 3 bugs.
WebKit now supports full page zooming on Mac and Windows. Because this feature involves new WebKit API, it’s not something you’ll see in nightly builds by default (since the Safari used with the nightlies calls the text zoom API). I have added a debug preference, though, that will cause the text zoom methods in WebKit to do full page zoom instead.
To try out full page zoom in a nightly, you can type the following in a terminal window:
defaults write com.apple.Safari WebKitDebugFullPageZoomPreferenceKey 1
We encourage people to try out full page zooming and file bugs on the feature.
CSS3 has introduced a property called background-clip that can be used to clip backgrounds to either the border, padding or content box. I have extended this property with a fourth value, text, that causes the background image to clip to foreground text (including decorations and shadows). The shape of the foreground content (including alpha transparency in the content) is applied as a mask to clip background drawing for the box.
Here is an example:
<div style="background: url(http://webkit.org/images/green-background.png), black; border:5px solid black; padding:5px; -webkit-background-clip: text, border; color: transparent">
This background clips to the text.
</div>
And here is how it looks (if you try it out in ToT):
This background clips to the text.
This effect can be used with -webkit-text-stroke and a transparent -webkit-text-fill-color to create text with stroked outlines that is “filled” with the background.
In addition, this visual effect can work with fixed backgrounds, so that text can look like it’s “punching a hole” through to the viewport.
Are you a university student? Would you like to get paid to hack on WebKit? WebKit is participating in Google’s Summer of Code. Google will pay you to work on WebKit for the summer. Coding sure beats flipping burgers.
Google begins accepting applications March 24th, 2008. We’ve posted some example project ideas to start your thought processes. Some highlights:
Prospective applicants should read Google’s student application instructions and join #webkit on freenode.net to meet the WebKit community. We’re happy to answer any questions about possible projects or mentors. Join #gsoc to ask the Google folks any administrative questions you may have.
We look forward to hacking with you this summer!
This one didn’t actually involve any code changes. Rather, the Acid3 test itself was changed as a result of feedback from the browser developers. The issue was some rather obscure details of click() DOM method which are not specified anywhere but are implemented in certain way by all browsers (more details in this thread). The behavior expected by earlier versions of the Acid3 was different and would have broken some web content. The ongoing HTML5 work will allow standardizing these kinds of details.
It is good to see that besides testing many exciting new standards Acid3 also takes real-world web compatibility seriously.
I’ve fixed Acid3 test 11, a test case of exception codes from Range.surroundContents. The fix involved changing the exception checking code at the start of the rather complex Range::surroundContents core DOM method. As you can see, this wasn’t a very complicated change.
This brings up another point about Acid3. Elsewhere on the interblag, some have argued that Acid3 is not an important test because a lot of what it tests are edge cases or obscure technologies. Our own Dave Hyatt downplayed the importance of the numeric score. It’s true that acid tests like this are not thorough standards compliance tests, and often enter the realm of very obscure standards details. But Acid 3 tests a lot of technologies that matter to everyday web development. While some tests are crazy edge cases, others are meat and potatoes interoperability issues that web developers have to work around today. Keep in mind that while the tests cover quirks of particular features, they also incidentally test much bigger gaps, for example the fact that some browsers are missing certain features entirely.
Some of you have also mentioned that you get slightly lower scores than the high score most are getting, or that some tests fail sporadically or on reload. I’m not entirely sure, but I think many of you are running into bug 17672, a timing issue that we’ll have to fix to fully pass the test. There are also a few remaining rendering issues we have to resolve, in addition to fixing the 8 remaining tests, to claim a full pass. Still, I’m pretty excited about the progress we have made so far.