|
Now that WebKit has its own web site on OpenDarwin, it's time for this blog to change. For starters, Surfin' Safari has now moved to here. Another big change is that I will no longer be the only person talking to you about Safari and WebKit changes. Some of the other members of the team will be posting about what they're working on as well. I will leave this blog up here so that all the links remain valid, but all subsequent posts will be to the new blog. Update your bookmarks. :)
Link Email item
Nokia uses WebCore in a new mobile browser for the Series 60 platform.
Link Email item
We've already received and committed several patches from external contributors and the repository has only been live for a few hours! As some of you have already noticed (those of you that built), the new Web Kit not only passes Acid2, but it's also substantially faster at loading Web pages and at handling JavaScript. It contains a number of additional performance improvements that went in post-Tiger. One question people have asked is "Does this have to replace my system frameworks?" The answer is "No." You can run this custom version of Web Kit with a particular instance of Safari without replacing your system frameworks. The run-safari script we provided does this for you. If...
Link Email item
As some of you may have heard at WWDC Monday, the Safari team is proud to announce that we are making significant changes in the way we operate, and these changes start today. Here is what we are launching: 1. webkit.opendarwin.org, the new web site for WebKit, WebCore and JavaScriptCore.
2. Full CVS access to WebCore and JavaScriptCore, our frameworks based on khtml and kjs. This repository includes the complete history of the project, so all patches past and present can be viewed.
3. WebKit, the Objective-C API that wraps WebCore, is also being open sourced. It is in the same CVS repository.
4. This repository is live. You can pull...
Link Email item
One of the most interesting problems (to me at least) in browser layout engines is how to implement a style system that can determine the style information for elements on a page efficiently. I worked on this extensively in the Gecko layout engine during my time at AOL and I've also done a lot of work on it for WebCore at Apple. My ideal implementation would actually be a hybrid of the two systems, since some of the optimizations I've done exist only in one engine or the other. When dealing with style information like font size or text color, you have both the concept of back end information, what was specified in the style rule, and...
Link Email item
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.
Link Email item
 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...
Link Email item
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. 
Link Email item
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...
Link Email item
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...
Link Email item
(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...
Link Email item
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...
Link Email item
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,...
Link Email item
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.
Link Email item
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.
Link Email item
Website
| 
