What’s Next in HTML, episode 1

Welcome to "What's Next in HTML," where I'll try to summarize the major activity in the ongoing standards process in the WHAT Working Group. Wait... what happened to This Week in HTML5? Hell, what happened to HTML5? Well, nothing. It took over five years to create, but it's in Last Call now. By all measures, it has already been wildly successful. Browser vendors are implementing it, books are being written, we have a kick-ass validator, web developers are slowly catching on, and there's still plenty of time to send us your feedback. But in the meantime, the WHAT Working Group has begun work on new, experimental features for the next version of HTML.

The next version of HTML doesn't have a name yet. In fact, it may never have a name, because the working group is switching to an unversioned development model. Various parts of the specification will be at varying degrees of stability, as noted in each section. But if all goes according to plan, there will never be One Big Cutoff that is frozen in time and dubbed "HTML6." HTML is an unbroken line stretching back almost two decades, and version numbers are a vestige of an older development model for standards that never really matched reality very well anyway. HTML5 is so last week. Let's talk about what's next.

The big news in HTML is r4439, which adds the device element. What's a <device> ? I'm glad you asked.

The device element represents a device selector, to allow the user to give the page access to a device, for example a video camera. The type attribute allows the author to specify which kind of device the page would like access to.

So it's for video conferencing, something you can currently only do with Adobe Flash or other proprietary plugins that sit on top of your browser. In fact, most of the pieces for browser-based video chat are already in place. The idea is that a device element would go hand in hand with a video element and a web socket. The device records a video stream (using the also-newly-defined Stream API) and sends the stream of video along a web socket to the other party (perhaps via an intermediate server) which renders the stream in a video element. And like the video element, the device element would be native to your browser, so browser vendors would not have to wait for third parties to add specific support for their platform.

Does all that work yet? Hell no. We don't even have a standard video codec yet! Google Chrome is the only browser that has shipped an implementation of web sockets (although it's part of WebKit, so presumably Apple could ship it in a future version of Safari if they choose). And the entire device API is still in its infancy. Nobody has even started implementing a prototype of that piece yet, and the whole idea might be scrapped by my next episode. But that's life on the bleeding edge.

And now you know "What's Next in HTML."