Archive for October, 2010

While the release managers were busy with the release of Chrome 7, the rest of the developers checked in another 635 changes. Meanwhile, over at WebKit, 498 more changes contributed to another busy week.

As part of the ongoing effort on making the Web Inspector tools as convenient as possible, Pavel Feldman continued workon merging the Storage and the Resources panels. The new panel contains both the storage items as the resources used to build the current page, combined in a clear tree view. Meanwhile, the Network panel UI has been polished a bit, which hopefully brings it a bit closer to being released.

Google’s Ben Murdoch added support for two new methods on the Document object: document.createTouch and document.createTouchList. Until now, these two properties were only available for the iPhone browser, but since other WebKit-based mobile browsers are gaining strongly in popularity, as well as the fact that many websites use them to check for touch-support, it made sense to add them to the document object.

No, it did not open Anne van Kesteren’s website in some ancient proprietary browser, this actually happened in the latest Chromium build. A subject I have deliberately not mentioned in my posts is Dave Hyatt’s amazing work on supporting the text and block-flow defined in the CSS3 Writing Modes module. Last Thursday a patch landed adding the possibility to have vertical text on your pages.

While there’s still a lot of work to do before the implementation will be finished, you can play around with it by downloading a Chromium build and using the “-webkit-writing-mode” property with the “vertical-rl” value. The feature has been available in Internet Explorer since version seven as well.

The Web Inspector Storage Panel has been updated with errors, warnings and search.

The File API has been updated with the latest specification changes, mostly related to error codes.

I’m hoping to publish a blog post about the CSS writing modes in the next week, as there certainly are a lot of interesting things to talk about. And, of course, another last week update in about seven days!

With another 1080 commits decorating the repositories there’s enough to tell you about last week again.

There has been a lot of discussion surrounding the about:labs page last week. Firstly, it has been renamed to “about:flags“, and for good reason: almost all criteria for adding new entries to the page have been lifted, meaning that pretty much everything which has a command line flag may have a place on that page. While this obviously is a good thing for convenience, it also means something could be enabled which constantly crashes Chrome. For that reason, the “–no-experiments” flag has been added.

Within WebKit support for the “onreadystatechange” event on the Document has been added, anchor elements now have the getParameter method from Adam Barth’s URL API and canvasses are now aware of the currentColor color. Also, all IndexedDB related properties on the window object have been prefixed with “webkit”. Unfortunately, support for <script defer> has been reverted.

The Chromium Team chose to enable their implementation of the FileSystem API by default. The API, which still is rather unknown among developers, has been built on top of two other specifications: the File API and the File Writer API. When you combine them and throw in some directories, Chrome’s latest feature comes out.

One of the larger use-cases I can see with the API is its ability to act like an extensive, hierarchic and programmable Application Cache. Suppose you’re making an online application which works like Spotify, the interface, playlists and all could be stored offline using a manifest, but the music itself wouldn’t be available offline. Using the FileSystem API, you could create a directory for each playlist and store the audio-files in them. There is a downside too, as the advocated API is asynchronous, it has a steep learning curve.

Other changes this week include:

Chromium now supports 5.1 surround sounds, no more downmixing to stereo.

Only three commits short of 700 in the past week, the Chromium Team has been quite active. The Chromium nightlies have been pushed up to version 8, just over seven weeks after version seven. WebKit received 485 commits, but there were some large changes among them like support for ECMAScript 5′s Strict Mode.

Well over two years after Eric Lake filed Issue 173, there is finally some visible progress on previewing a print in Chromium. When using the latest nightly, you should launch Chrome using the “–enable-print-preview” flag and browse to “chrome://print/” to see a (not working!) preview of the feature. Enabling the Cloud Printing Proxy for Windows may now be done through the Labs page and a lotof work on supporting the CSS Paged Media Modules has been completed already. The feature is currently scheduled for milestone 9, which may be as soon as six weeks from now.

Another large change is that support for IndexedDB has been enabled by default. IndexedDB is a specification originally proposed by Oracle, but currently is being edited by experts from Google, Mozilla and Microsoft as well. Especially the latter makes this interesting, because since Opera’s Charles McCathieNevile has been positive about IndexedDB as well, chances on getting an interoperable database system are looking good.

Many of these features are still disabled in the Chromium builds. If you’d like to play around with them, you will either have to build Chromium yourself or create yourself a WebKit build. In time these features will be enabled for all Chromium builds, something which surely will be announced on the Chromium Blog.

Also great news for the Safari users, as Oliver Hunt landed support for ECMAScript 5′s Strict Mode just a few hours ago. In a nutshell, strict mode will disable some really bad practices in your JavaScript code like eval() and the with-construct. These changes couldn’t be applied by default, considering ECMAScript 5 had to remain backwards-compatible with ECMAScript 3. Until today, Kangax’ compatibility page shows that BESEN was the only JavaScript engine to support it, although Mozilla is actively working on supporting it.

Finally I just want to note down that I really don’t think recordings like these are going to make me popular, even though Christian Heilmann obviously thinks otherwise. A big thank you to the organization of Fronteers 2010, all the speakers, and of course all the visitors. The conference has been really great, cheers for that!

With 632 commits to the WebKit repository, and 608 towards the Chromium one -totalling 1240 commits-, it was a busy week. Safari seems to be gearing up for a new minor release, and Google pushed Chrome 7 to users participating in the beta-channel. Google also published a page explaining the differences between extensions, Packaged Applications and Hosted Applications.

Nikolas Zimmermann has done some amazing work on WebKit’s SVG implementation: almost all SVG Text layout-code has been rewritten. Because of this change, text in SVG files already consumes much less memory and performs better than it used to do. By splitting the layout process for texts into three phases rather than a single one, future patches can add various forms of caching. This will improve the rendering performance even more.

Following the WebM project, which provides a free and open-source video codec, Google has announced WebP: an image format based on VP8′s intra-frame techniques. According to Google’s announcement, using WebP will reduce the size of your images by an average of 39%, compared to today’s image formats.

In reality, I’m not so sure. Jason Garrett-Glaser, an x264 developer, concluded that the quality is poor, and that Google’s timing for announcing the format is odd. Jacob Miller, obviously being less biased, concluded that the compression schema indeed outperforms JPEG, but that WebP isn’t ready for real-world usage yet.

I absolutely agree that the timing surrounding this announcement is weird. There are some important features not (yet) available in WebP which could prove to be decisive in the success of the image format. I’m mainly talking about the limited file size it supports (a maximum of 16383 by 16383 pixels), no support for storing lossless images and no transparency (nor translucency?). For a future-proof image format, Google could also have looked at supporting other color-spaces (possibly even non-RGB, like the CIE XYZone). It makes me think like the announcement was a bit rushed, especially due to a sentence starting with “we plan to add”…

In my opinion, one of the primary things lacking for web development was a convenient way to modify the classes which applied to an element. While jQuery offered some excellent methods to do so, a proper native way wasn’t available. For that reason HTML5 introduces the “classList” property, which provices such an interface to each element on your page. While support for the property was added to Firefox well over a year ago, Erik Arvidsson added support to WebKit last Monday!