Canvas is working. Some work has been done to integrate <canvas> with video on the trunk, although this is not an active area of development by the team. Much of the progress on <canvas> comes from code being checked into WebKit, there is little code specific to Chromium.

Video and audio support shipped in the 3.0 build. Work at this point is focused on targeted on bringing mac and linux up to parity with windows, in time for the mac and linux beta releases. Linux is currently further along than Mac. Future work will focus on performance. Currently we do everything in software (decode and rendering), whereas Flash uses hardware acceleration for part of the rendering. This results in <video> having a nontrivial overhead over Flash, especially on low-end CPUs (e.g. netbooks). We are looking into what we can do, including utilizing the GPU, to improve performance.

Dedicated workers are enabled by default in Chrome 3.0. Currently there is a limit to the number of workers that each page can start, as well as the number of workers that can be running globally across all pages. This is because we start a new process for each worker. We plan to address this, but it requires changes in v8 that are not likely to happen until late 2009 when v8 adds support for "isolates". This also prevents Android from using workers and v8.

Done, and included in 4.0

MessagePorts are done, and are included in 4.0.

Application Cache work is ongoing. Currently focusing on the application logic behind the cache with the goal of having an in-memory version working (with no persistence to disk). Large parts of the logic, such as the cache selection algorithm and update logic, are functioning and we're finding/fixing issues turned up by system testing our implementation. Once the logic and algorithms are working, the next step will be to persist the data to disk and add some rudimentary quota management. Currently targeting early January for this feature.

The Database API is currently behind a flag on the dev channel (--enable-databases). Our implementation is code complete at this point, and we're shaking out some bugs. Should be out from behind a flag real soon now.

The localStorage part of Web Storage (aka DOM Storage) is currently shipping in the dev channel and should ship in 4.0.  We have decided not to implement the storage mutex or storing structured clone data for now and are taking a "wait and see" approach.  SessionStorage is on target for mstone 5.

Web Sockets is enabled by default on Dev (4.0.238.0 or later). Web Sockets in Worker is not yet available. You can try Web Socket with server, such as pywebsocket. Currently targeting a 4.0 release.

The team has focused on helping to create a spec for what the behavior should be of certain sequences of events inside of contentEditable areas, e.g. where the cursor should appear if you skip over a word, behaviors for selection, and the like. The hope is that this will inform a spec that can drive browsers towards a uniform set of behaviors. Beyond that, much work has been done to fix various bugs in the WebKit implementation of contentEditable.

Work continues on bugfixing and implementing CSS3 layout features, including most recently bugfixes in selctors. (More info to come in this section next week)

Mostly done, some patches waiting to land in WebKit. 

We are landing support for @font-face in the 4.0 release.

We have implemented some basic support (e.g. validation state). This is a large feature, most of the visible parts (e.g. most of the input types) will not actually be landing until Chrome 5 or later.

Desktop notifications

Targeted for M5

Drag-n-drop enhancements

Add support for dragging files / data-streams out of a web page. Some of this has already landed, but it is a work in progress and likely not to be complete until Chrome 5.

FileData

FileData implementation is under-way.  Adds support for reading the contents of a FileData reference retrieved from a HTML <INPUT type="file"> element.  Includes support for FileData.url, allowing the FileData reference to be loaded as an URL by ordinary HTML elements (e.g., IMG, VIDEO). There is more work to be done in terms of fleshing out what additional APIs / use cases need to be supported, this should be complete in Chrome 5.

SessionStorage (in progress, not enabled by default on Dev)

The sessionStorage part of Web Storage (aka DOM Storage) is currently behind a flag (--enable-session-storage).  It's fully functional within one renderer process, but if you navigate to another origin or close and then restore a tab, your data will be lost.  SessionStorage is on target for being complete in time for mstone 5.

There was a recent proposal to whatwg@ to add something called a "GlobalScript", which is a script context that can be shared between multiple windows or tabs on the same origin, to speed up complex web applications that commonly use multiple windows (or are opened multiple times). Discussion continues on whatwg, with an implementation to follow.

http://dev.w3.org/html5/webdatabase/#synchronous-database-api

We need the ability to persist FileData references locally, allowing an application to recover a FileData reference later.  This feature is not yet spec'd.