Surfin’ Safari

There have been a lot of exciting new engine-level features that have been added to WebKit over the last few months, and not all of them have received their own blog entries. Since we featured some of these in Safari/WebKit WWDC presentations, now seems like a good time to mention some of the highlights of the cool new things you can find in WebKit nightlies:

• JavaScript getters and setters - pretty much the same as getters and setters in Mozilla.
• DOM class prototypes - now you can get direct access to the prototype objects for DOM classes, e.g. HTMLElement.prototype, to do the same kind of prototype hacking you can do in Mozilla.
• Undetectable document.all, for compatibility with web pages that use it without checking.
• Much improved support for HTML editing, including execCommand support for InsertOrderedList, InsertUnorderedList, Indent, Outdent, HiliteColor, RemoveFormat, FormatBlock, FindString, InsertHorizontalRule, InsertImage, InsertHTML, Unlink and CreateLink.
• Significant JavaScript speed improvements, adding up to 20-30% improvements on benchmarks such as the JavaScript iBench and the 24fun BenchJS.
• Significant DOM XPath support including some of the Mozilla and IE extensions.
• Mozilla’s XSLTProcessor extension.
• CSS3 Media Queries
• New CSS3 properties including resize, background-size, border-radius (now complete), overflow-x and overflow-y.
• Continued progress on styleable form controls - textarea and pop-up menu select (but not the list box kind) are now styleable.

This is just a sampling of some of the great new web content features that WebKit supports. If you would like to see these and more in action, try a nightly build or check out the code.

Yesterday Apple announced Mac OS Forge, a new developer community site for selected Mac OS X open source projects. Currently hosted projects include the Darwin Calendar Server, Bonjour, Launchd, and the Darwin kernel, including full intel sources. Congratulations to the team behind Mac OS Forge, and welcome to our open source brethren.

In conjunction with the Apple World Wide Developers Conference, the Safari/WebKit team at Apple will be hosting a WebKit Open Source party. If you are a Mac OS X developer, a browser hacker, a web developer, or just someone with an interest in cool technology, then come hobnob with WebKit contributors from Apple and elsewhere.

Unlike WWDC itself, this event will be open to anyone who is interested free of charge. Also, it will be unbelievably awesome. We promise!

Details:

Place: 111 Minna Gallery (map)
Date: Tuesday, August 8th
Time: 7 PM

The KDE team recently anounced the Unity project, an effort to port WebKit to Qt 4. WebKit was originally derived from KHTML, the html rendering engine for KDE. Since then, the two engines have followed separate development paths. But with this effort, we have the opportunity to once again have a single source base that works on both Mac OS X and KDE.

We are looking forward to merging in the porting patches from KDE, and to merging general improvements from KHTML that are not yet in WebKit. Working together with KDE and with our friends from Nokia, we can continue to build a world-class web rendering engine.

I would like to introduce a new addition to the WebKit open source tools—a JavaScript debugger. Drosera, named after the largest genera of bug eating plants, lets you attach and debug JavaScript for any WebKit application—not just Safari.

One of the unique things about Drosera, like the Web Inspector, is that over 90% of it is written in HTML and JavaScript. This is a true testament of what you can do with web technologies today and the rapid development that WebKit allows.

So update your tree or download the nightly and give Drosera a try. The nightly always has JavaScript debugging enabled, you just need to attach from Drosera. However, to attach to Safari with your own WebKit build you will need to type the following once in the Terminal:

defaults write com.apple.Safari \
WebKitScriptDebuggerEnabled -bool true

To debug your application’s JavaScript you will need to enable this default for your application’s bundle identifier. Additionaly you need to launch your application using the TOT WebKit frameworks. You can easily do this with the run-webkit-app script inside WebKitTools/Scripts, then you will see your application show up in Drosera’s attach window.

Our bugzilla now has a Drosera component, so please feel free to file any bugs, enhancement requests and especially patches!

I am at the moment sitting at the World Wide Web Conference 2006 in Edinburgh where Nokia announced a few mintues ago to open source its S60 WebKit sources. We are releasing our code under the terms of the open source BSD License, and our source code will be made available through the WebKit Open Source Project site. The code that we are contributing includes many mobility components that are needed for a basic browser, including items such as a memory manager, mobile usability improvements and a reference user interface. In addition we have prepared a number of testing tools and documentation to get you as a developer quickly started, go check it out. As we are moving forward we will be making improvements to tools and release further features.

It has been exciting and at times challenging one and a half years for us to develop our new mobile Web browser for the S60 software platform based on Apple’s and KDE’s fantastic Safari and Konqueror browser code. I wanted to take the opportunity to thank the KDE community, WebKit community and the Apple Safari team for having built what is today WebCore and JavaScriptCore, a large part of your code is today already running in our Nokia mobile phones. We at Nokia are looking forward to working together with many of you from the community and partner companies in the near future to further develop the S60 WebKit.

The Web goes mobile!

Alexey Proskuryakov is now a qualified WebKit reviewer. Please congratulate Alexey, and/or beg him to review your patches.

As you may be aware, Nokia’s new Web browser for S60 uses the WebCore and JavaScriptCore components from Apple’s WebKit. We first released the code as a zip file on http://opensource.nokia.com.

In line with our plans to work in the public we have now placed these zip files on a branch in svn, http://trac.webkit.org/dev/browser/S60/tags/s60-051212. This is an interim migration of the S60 WebKit port. Currently only the December 12, 2005 release of the S60 branch for JavaScriptCore and WebCore are on opensource.apple.com. Since early December 2005 the S60 WebKit team has not modified that source tree.

We will soon migrate the up-to-date, active S60 WebKit branch - including an example browser implementation - into the svn/webkit/S60/trunk. Starting then all S60 WebKit development will be on anonsvn.opensource.apple.com.

So please watch this space!

I figured I’d take another stab at educating people about CSS units.

In the responses both on this blog (and on Slashdot), some people argued with the high DPI proposal saying “A pixel is just a pixel! Making a CSS pixel != screen pixel is a bad idea!” Those of you who think this way have a fundamental misunderstanding regarding how the Web works even today. It is already true that a CSS pixel does not necessarily equal a device pixel, and there’s nothing wrong with doing this. It doesn’t mess up your Web site. You don’t even have to think about it if you don’t want to.

For example, whenever you zoom in a browser that supports it (like Opera), a CSS pixel won’t equal a screen pixel. Nor should it, since otherwise the zooming wouldn’t be possible. The zooming, done well, doesn’t hurt your Web site or disrupt its layout in any way, since everything zooms together. The high DPI proposal I outlined earlier is about defining how a Web site can intelligently reveal higher levels of detail when zoomed rather than just scaling up the exact same content.

Another example of where high DPI already comes into play is with printers. Printers can have very high DPI, and if you made a CSS pixel = a device pixel, your Web site when printed would be so tiny that you wouldn’t even be able to read it. Pixel scaling is already done at the printing level.

In addition to being muddled about the px unit, some people were confused about the so-called absolute units. These include units like pt or cm. These units actually aren’t absolute. The absolute unit is a myth.

The sad truth is that designers never really understood the difference between pt and px. Many Web sites even today mix those units in the same Web page. Not only do they assume that pt and px are close to one another in size, they actually mingle these units assuming that the ratio between these two units will be constant across all browsers and devices. Any browser that truly attempted to treat pt as 1/72nd of a physical inch would just end up mis-rendering Web sites.

This is why browsers use the 96 dpi rule when deciding how all of the absolute units relate to the CSS pixel. When evaluating the size of absolute units like pt browsers simply assume that the device is running at 96 CSS pixels per inch. This means that a pt ends up being 1.33 CSS pixels, since 96/72 = 1.33. You can’t actually use the physical DPI of the device because it could make the Web site look horribly wrong.

The other units worth discussing are em and ex. These units are interesting to use primarily because of the text zoom feature of Web browsers. Because some browsers (like Safari and Firefox) just zoom text without zooming other content, expressing everything in these units can give you a way of having content other than text also scale with the font size.

In reading responses to my initial post I noticed a bit of confusion regarding the proposal. In particular people seemed to think I was proposing some sort of mandatory changes (e.g., fix your Web site or it will break!). That is not what I was saying.

Designing for higher DPI screens is about making your Web site look better when presented in the same amount of physical space on a screen with more pixels. It is purely optional. If you do nothing at all, your Web site will still look essentially the same even when magnified (assuming your system has done a good job with scaling).

Think about TVs for a second instead of computers. In particular, consider DVD content vs. HD content. If you own an HD television set, you can still watch DVDs and have them look great… but you could also watch that same content in HD and have it look even better. Your DVD content is effectively being zoomed on an HD set. HD content will show you more detail because it displays more distinct pixels of information in the same amount of physical space.

The same thing should end up being true of Web sites when they are magnified on screens, and that’s what this proposal is trying to make clear. Note that I’m not even talking about particularly high DPI screens. Many people who own 1920×1200 laptop screens already wish they could easily scale their whole UI now. (This is something that computer geeks with keen vision sometimes can’t appreciate.

The fact that Web content will be zoomed (either via a browser-level feature or an OS-level feature) is inevitable. It’s important that browsers have agreed-upon behavior for how Web sites should behave when the content is magnified so that designers have the ability to present a higher level of detail to users who would like to have the “HD” Web viewing experience.