Surfin' Safari

Front Page  -  Technorati

KHTML developers respond to my posting of the WebCore Acid2 patches here and here.

For what it's worth, the patches I posted are to WebCore, which consists of both KHTML and KWQ (our port of Qt). They are posted to illustrate all the WebCore bugs that had to be fixed in Safari to pass the Acid2 test. They are not solely KHTML patches. The antialiasing bug was in KWQ, and so doesn't even apply to KHTML. The better object element support necessarily involves KWQ as well, since the plugin code is (obviously) platform-specific.

What do you think Apple could be doing better here? Comment or trackback. I'll read it all.

Safari now passes the Acid2 test. There were two issues left that needed to be resolved.

The first issue involved implementing a few enhancements to the object element. I needed to support fallback content when invalid MIME types were specified or when bad status codes were returned for HTTP requests (like 404). After fixing these bugs and a couple of other problems with intrinsic sizing of plugins, the eyes of the face showed up.

The second issue involved improper antialiasing of the border corners. Antialiasing was enabled for the drawing of the corner polygons, and this resulted in a bleed-through of the background. Because the two corners were drawn separately, the antialiasing was actually incorrect, since it was disrupting the join of the corners by letting the background show.

Here are the patches for all of the problems fixed in Safari to make the test pass.

Fix parsing of the REL attribute on links.

Disallow TABLE inside P in strict mode.

Add support for min/max-width/height for positioned elements.

Fix the rendering glitch that causes the reference page to paint garbage.

Make sure that percentages that go to auto don't mess up the self-collapsing block check.

Implement SGML-style comment parsing for HTML in strict mode.

Make sure empty tables honor CSS-specified height in strict mode.

Fix baseline alignment within table cells to use the bottom of empty blocks. Fix floats to not grow if child floats overhang but the height of the outer float is auto.

Make sure percentage min-height goes to 0 and not auto when the percentage does not apply.

Implement fallback content for the object element and fix intrinsic sizing to work properly when images are specified in the object element.

Disable antialiasing for the drawing of polygons.

Victory!

The Acid2 test has been updated to version 1.1 in order to fix the bug I outlined in my previous blog entry. Here is how the Safari build with all of my fixes renders version 1.1. As you can see now we're just down to better object element handling.

Astute viewers pointed out that there was still a rendering glitch in row ten. It turns out this was actually a problem with rows six to nine. The block above ended up being too tall because min-height specified using a percentage was resolving to auto instead of to 0 when the containing block had no specified height. I fixed this problem, but check out the rendering now.

Observe how the smile is now positioned too high relative to the reference rendering. I spent a very long time investigating this problem and determined that it is in fact a bug in the test. At this point I am halting work on Acid2 until a revised test has been posted.

The purpose of this blog entry is for you to track back to it with regressions you have discovered going from 1.2 to 1.3. It would be especially helpful if you can test up front for whether this is a user agent bug (by spoofing as another browser), since changes in browser version numbers often cause regressions even when nothing is wrong with the browser itself.

The more clear and concise the reduction, the better the chances are that we can address the issue quickly (thus increasing the odds it can make it into a software update sooner rather than later).

Please include in these trackbacks only regressions from 1.2. If you included something in the earlier blog entry's comments section, please post it again as a trackback. Thanks!

(1) The feed URL dialog that tells you 10.4 must be installed to view RSS feeds is simply a bug and not part of a master plan for global domination.
(2) The View Source shortcut was changed to match Mail.app.
(3) The default bookmarks reappearing after being removed won't happen going forward now that the way this is handled has been changed. See (1) above re: global domination.
(4) The selection extends to the edges of lines in the new Safari just as it does in other Mac apps like TextEdit. This change had to be made so that editing selection would behave like NSTextView. It was a challenge translating this to the Web space, but I will blog more about this in a future entry.
(5) When saving links to the desktop from the context menu, you can hold down Option to change the menu item so that you can pick a location.

Even though I consider row 14 to be ambiguous, I went ahead and modified the Safari code to yield the correct expected behavior. It isn't so much that the test is wrong as that it is testing unspecified behavior.

I also noticed thanks to Ian Hickson that the smile was not in fact rendering correctly. The reason is that Safari will expand floats to encompass overhanging child floats even when the outer float has specified a height explicitly in CSS. I changed the code so that this is now only done when height is auto, and the smile now renders as it should.

Updated screenshot below. All that I have left is fixing the object element's behavior in order to completely pass the test.

Those of you running Panther can now update to 10.3.9. This update includes Safari 1.3 and new versions of WebKit, WebCore, and JavaScriptCore that contain thousands of improvements we've made to the engine since Safari 1.2.

What you are getting is all of the new standards support, new WebKit capabilites, site compatibility fixes and performance optimizations that are also present in Safari 2.0 for Tiger. The layout engines for the two are virtually identical.

Here are some of the highlights:

Page Load Performance
Safari 1.3 loads pages overall 35% faster than 1.2 as measured by IBench. In addition to improving the overall page load, Safari 1.3 will display content sooner than 1.2 did, so that subresources don't hold up the initial display of the page.

JavaScript Performance
We have substantially improved the performance of the JavaScript engine in Safari. I encourage you to check out Safari 1.3 on this benchmark for example to see the improvement relative to 1.2.

HTML Editing
Safari 1.3 supports HTML editing, both at the Objective-C WebKit API level and using contenteditable and designMode in a Web page. The new Mail app in Tiger uses WebKit for message composition. You can write apps that make use of WebKit's editing technology and deploy them on Panther and Tiger.

Compatibility and Security
Compatibility and security are our number one priority in WebCore, and Safari 1.3 has many important compatibility fixes. For example, percentage heights on blocks, tables and cells now work much better in Safari 1.3. min/max-width/height support has been added. More of the table-related CSS properties are now supported. DOM methods like getComputedStyle are now supported.

The DOM Exposed
The entire level 2 DOM has been exposed a public API in Objective-C. This means various holes have been filled in Safari's DOM level 2 support. In addition to exposing the DOM to Objective-C, the JS objects that wrap DOM objects can also be accessed from Objective-C, allowing you to examine and edit the JS objects themselves to inject properties onto them that can then be accessed from your Web page.

XSLT
Safari 1.3 on Panther now supports XSLT. 10.3.9 includes libxslt, and Safari uses this excellent library to handle XSLT processing instructions it encounters in Web pages.

Plugin Extensions
For those of you writing WebKit apps, a new Objective-C WebKit plugin API is supported that lets you put Cocoa widgetry into the Web page more easily. In addition enhancements to the Netscape Plugin API (made in conjunction with Mozilla Foundation) have been implemented for plugins that require cross-browser compatibility.

Did I mention it's really really fast? :)

In case you're curious about differences between the Tiger and Panther versions of the engine, they mostly have to deal with frameworks that changed underneath WebKit. For example we have new faster image decoders on Tiger (that also handle PNGs correctly), so you'll find that Tiger fixes some of the PNG gamma issues that will still exist on Panther. In addition the new decoders are incredibly fast and are now run on a separate thread on multi-processor machines on Tiger.

The network layer has also been improved on Tiger, so this may be another source of differences in behavior between the two operating systems. Overall, however, it's likely that content and applications you develop with WebKit will behave identically on the two operating systems.

Let us know what you think.

I believe row 14 is ambiguous and needs to be amended. Safari makes this row too tall for the same reasons Firefox does.

See https://bugzilla.mozilla.org/show_bug.cgi?id=289480#c14 for more details.

Earlier I asserted that Safari passed rows 6-9. Now I'm not so sure. As someone in the comments pointed out, Safari has a 1px golden ring around the black nose that is not there in the reference rendering. I will have to figure out what causes this to see if it's a bug in Safari.

Ok, I now pass row thirteen. In strict mode I just made comment parsing flip a canClose bit as it encountered pairs of --. For an even number of --, you can close when you encounter a >. That fixes the rendering. I'm not sure this is correct, but hopefully it is. :)

I must admit that I am completely baffled by row thirteen. The row includes a comment that Safari appears to be handling incorrectly, but I have no idea why. There is apparently something I don't know about comment handling. Can someone from WaSP clarify and explain what the heck I'm supposed to do with this line?

<!-- -- --->ERROR<!- ------ ></div></div> <!-- two dashes is what delimits a comment, so the text "->ERROR<!-" earlier on this line is actually part of a comment -->

This particular comment test seems particularly esoteric and pointless to me. It's clear that I'll have to limit this parsing rule to strict mode anyway, since I doubt other browsers make you count hyphens when constructing comments.

I'm a bit perplexed that a test that is supposedly testing features that WaSP considers "essential" for the future Web contains data URLs and esoteric SGML comment rule tests. What about inline-block? I consider that far more essential than whether or not a browser can handle some obscure comment parsing rule.

I spent some time studying rows four and five of the test and realized it would take a while to fix. Those rows are testing using the object element without specifying a MIME type and making sure that if the types are unsupported that you fallback to nested objects. I have ideas for how to fix this, but I decided to save this part of the test for last.

Instead I focused next on why there was an odd six pixel gap between rows nine and ten in Safari. It turns out that my check for whether or not a block could collapse its own margins together was missing a case, and the Acid2 test had a nice comment explaining what I was missing.

.empty { margin: 6.25em; height: 10%; /* computes to auto which makes it empty per 8.3.1:7 (own margins) */ }

Basically I needed to improve my self-collapsing block code to be smarter about noticing when percentage heights end up turning into auto. Once I fixed that, the gap went away. Below is the current rendering after the bug fix.

I also noticed that the test and the reference rendering apply overflow:hidden to a root element and expect that to be applied to the viewport. Safari 2.0 does this for HTML documents with the body element but did not ever do this with the root element. I fixed Safari to actually behave according to the latest internal draft of CSS2.1 and now the documents don't have scrollbars.

I have finally completed the implementation of the CSS properties min-width, max-width, min-height and max-height in WebCore. Safari 2.0 (and Safari 1.3) both support these properties on everything but positioned elements. It figures then that the use of these properties on the Acid2 test would occur on positioned elements (thanks Hixie!).

Included below is a screenshot of the rendering in Safari with this bug fixed.

As you can see, rows 1-3 and rows 6-9 all render correctly. I'm going to work on rows 4 and 5 next and see if I can get the eyes of the face to show up.

The Web standards project has released the Acid2 test for Web browsers. It is a pretty crafty HTML+CSS test designed to ensure that browsers are properly implementing support for those standards.

Every browser fails it spectacularly. :)

I started work today on making Safari pass the test, and I thought I'd blog my progress as I fix bugs in the test. This will be a fairly slow process as whole features may have to be added simply to make one row of the test render correctly.

For those using Safari, I have fixed two bugs so far. The ugly red background that covers the test is caused by a bug in Safari's parsing of the rel attribute on links. Safari had some hard-coded checks for keywords rather than doing proper space-based tokenization of the attribute. I fixed this and now the red background is gone.

Row one in Safari mis-renders for two reasons. The first is that the test wants to make sure table elements are not allowed inside paragraph elements in strict mode. Safari did not have a tight check here, and allowed tables inside paragraphs in all modes. You have to allow this in quirks mode because other browsers do, but I went ahead and tightened the check for strict mode. With this bug fixed, the first row's maroon line became black as it should.

The second problem is that the first row's black line is the wrong height and the wrong width. This is because Safari 2.0 supports min/max-width/height on everything but positioned elements. I will have to add this support to make row one finally render correctly, so that's what I'll be working on next.

'Nuff said. Best. Game. Ever.