There have been some interesting movements in the browser landscape lately: Opera moving away from Presto, Chromium for Android and Firefox Mobile making a stronger stand on mobile platforms. Web Platform has less fragmentation right now than it ever had before. Today, the Chromium project introduced Blink: a new open source rendering engine based on WebKit.

I’ve been a contributor to the WebKit project for a few years now, written hundreds of updates about the project and even published dozens of those on the official weblog, Surfin’ Safari. It’s a great community, one that I’m very proud to be a member of. Working on WebKit introduced me to a great amount of people and taught me an incredible amount of things.

To improve the open web through technical innovation and good citizenship.
A few weeks ago, Max Heinritz introduced the new Chromium Feature Dashboard, listing not just the implementation status, but also the maturity, interoperability and testability of Web Platform features in Chromium. With Blink, Chrome is taking this one step further and are introducing strict guidelines new features have to adhere to.

To fulfill our good citizenship mission, we need to be careful to add new features to the web platform in a transparent, responsible, and compatible manner. We measure success as moving the open web platform forward as a whole, not just as moving one implementation forward.

I’m both positively surprised by and very confident in the way that Google’s Web superstars (Alex, Dimitri, Paul, Eric and many others) are making this happen. Google projects, including Dart, NaCL and others, are subject to the same guidelines in introducing their changes to the Web Platform as any other participant, including our very strong preference for standardization and compatibility with other browser vendors.

Compatibility risk will be one of the most important decision criteria for enabling new web platform features for the new engine. A launch process has been introduced for new features which touch the Web Platform, which includes several public announcements and reviewing steps. This is not just limited to Googlers: whilst getting commit rights for Blink is similar to the Chromium project, there is a fast track available for WebKit contributors. I’m also very hopeful that we’ll soon be welcoming the first non-Google OWNER to the project as well.

I’m a Web Developer. Thank you for making my life even more complicated!
Paul Irish asked a question about a month ago: what is WebKit? WebKit implementations are not homogenous: they differ in anything from the code used for downloading resources to the mechanism used to display pages, as well as in supported set of features. Chromium, Safari and other implementations of WebKit should already have been considered as separate testing targets.

All browsers’ latest versions are absolutely excellent from a technical perspective. With Ian Hickson’s HTML parsing algorithm and all the rendering engines coming increasingly close to passing the entire CSS 2.1 test-suite, we’re almost at a point where the true foundations of layout on the Web are both standardized and interoperable between implementations. The Chromium project now intends to take this further by working with the W3C to make sure both conformance tests and the testing infrastructure can be shared between different browsers.

Another area which I’m very excited about is that Blink will be following Mozilla’s ideas in regards to vendor prefixes. While support for legacy WebKit vendor prefixes will be maintained in the short term, Blink will strive to avoid shipping vendor prefixed features to the Stable channel altogether.

The end of the Last Week in WebKit articles?
I’ve published 114 articles describing changes in the WebKit and Chromium repositories that occurred in the week before. I do still intend to continue doing so, however, they will address Blink changes instead of WebKit’s. I won’t be posting updates to the Surfin’ Safari anymore, although I am definitely grateful I had the chance of doing so for a number of months.

Personally, I’m really excited about this change. The scale of the Web Platform asks for an ecosystem which doesn’t just welcome participation and collaboration, but also has a fair and healthy amount of competition. Jake made a great analogy about Blink’s potential in the near future: Blink can do for layout and rendering what V8 did for JavaScript, although the improvements will be more gradual.

I’m confident that Chromium can use Blink to increase diversity, while driving innovation, as it has shown to be capable of in the past. For more background on the why, I encourage you to read Alex Russell’s great post on the announcement of Blink. Justin also sheds some light on the security implications of this change, and Paul Lewis also shared some nice insights.

Read more (4 comments) »

Finally we’re able to provide an answer to the many rumors which have been going around in the past few months: Google Chrome is now available for Android devices running Ice Cream Sandwich. On my Galaxy Nexus, the browser scores 343 points on html5test.com, runs the SunSpider test in 1880ms and scores 1308 points on the v8 test.

Support for the Web Platform
The first beta uses the same basis as Google Chrome 16, meaning it has most Chromium and WebKit changes up to mid October 2011. I’ve already iterated through many of the changes which were included in that release, most of which will apply for the Android version as well.

To name some highlights, Chrome for Android supports pretty much all of the Web Platform’s exciting features, including CSS 3D Transforms, GPU accelerated canvas, CSS Animations, SVG, WebSockets (including binary messages!) and Dedicated Workers. It supports IndexedDB, Application Cache and the File APIs, date and time pickers, parts of the Media Capture API and mobile oriented features such as Device Orientation and Geolocation. Fixed positioned elements are also working and even look smooth while scrolling!

What the Android-based Chrome does not support is Flash, following Adobe’s announcement in November. Other unsupported features in the beta release are Extensions/Apps, WebGL, Shared Web Workers and the Web Audio API.

An issue that often pops up for mobile browsers is that text on the website may be too small to read properly. Where the Android Browser employs a text reflow algorithm to clarify the situation, Chrome for Android features a technique which we’ve called Font Boosting. It uses an algorithm to increase font sizes when necessary, aiming to make the text readable regardless of the zoom level.

And for the Web Developers among you, it’s also possible to utilize Web Inspector’s Remote Debugging feature to inspect and modify pages while viewing it on the device itself.

Google Chrome 16 and mobile limitations
Of course, bringing a browser to a different -much more limited- platform goes further than simply re-using code. Mobile devices have a lot of limitations compared to desktop and laptop machines. Besides the lower amount of available memory and CPU power, other constraints lie in less memory bandwidth and VRAM on the device’s GPU. Google Chrome has a complicated architecture which imposed some interesting challenges here: separating the browser from the renderers through its multiple process architecture, to name an example. Decreased rendering and scrolling performance were also an issue, to which Chrome’s GPU team provided an excellent answer in the form of a threaded compositor.

Another characteristic of the Android platform is that the APIs for most significant features are exposed through the Android SDK, making them available to Java code. To this end, part of the browser layer has actually been implemented in Java, communicating with the rest of the Chromium and WebKit code through Java Native Bindings.

Becoming part of the Chromium project: upstreaming our code
Chrome for Android has been developed in a separate repository as a fork, which means that most of the code will have to be upstreamed. To date, about 150 commits have landed in Chromium making many preparations, including the build environment and bots for Chromium and WebKit, not to mention WebKit’s umbrella bug and the two announcements.

As having a fork is far from ideal, one of the current top priorities will be to upstream most new and modified code to Chromium and WebKit, while the build and testing infrastructure on Chromium’s waterfalls is expected to evolve significantly. A snapshot of the current source-code of Chrome for Android can be downloaded as a tarball.

Of course, keep in mind that today’s release is just a beta; much more work, features and stability will be needed to actually be able to release the first stable version. Personally, I’m very glad that the project has been announced, and definitely am looking forward to continuing development in the open!

Read more (24 comments) »