HTML 5 is the fifth major revision of the core language of the World Wide Web and was pioneered in 2004 by the Web Hypertext Application Technology Working Group (WHATWG). Although the specification is ongoing work, parts of HTML 5 are already implemented in browsers like Safari 4 beta.
In addition to specifying markup, HTML 5 exposes several new scripting APIs:
- A 2D drawing API which can be used with a new canvas element for rendering graphs, game graphics, or other visual images on the fly.
- An API that allows a web application to register itself for certain protocols or MIME types.
- An API that introduces a new caching mechanism to support off-line web applications.
- An API for playing video and audio which can be used with the new video and audio elements.
- A history API that exposes the browsing history and allows pages to add to it to facilitate better back-button support in AJAX applications.
- Cross-document messaging which provides a means by which documents can communicate with each other regardless of their source domain, in a way designed to prevent cross-site scripting attacks.
- A drag & drop API to use in combination with a draggable attribute.
- An editing API to use in conjunction with a new global contenteditable attribute.
- A new network API to enable web applications to communicate with each other on local area networks, and to maintain bidirectional communications with their originating server.
- Server-sent events in combination with the new event-source element which will facilitate persistent connections to remote data sources and largely eliminate the need for polling in web applications.
- Dylan Schiemann, CEO of SitePen and co-creator of Dojo
- Matt Sweeney & Eric Miraglia, YUI engineering team
- Andrew Dupont, core developer of Prototype
- Thomas Fuchs, creator of script.aculo.us, and core developer of Prototype and Ruby on Rails
- David Walsh, core developer for MooTools
- Scott Blum and Joel Webber, GWT lead developers
Below you will find the questions asked and each participant's answers.
InfoQ: With HTML 5 still being a work in progress, not many developers are familiar with the new features that it brings. What features do you find most noteworthy for web developers?
Dylan: HTML5 is a very large topic. Many of the features that we find valuable are things that you already find in toolkits like Dojo. For example, richer form controls with native implementations are promising including multiple file uploads, as well as data attributes so people won't complain about Dojo using allowed but impure custom HTML attributes. Peter Higgins recently wrote a Dojo Parser patch in 1KB of code to support this feature once browsers add it. That said, the single most interesting feature to me is the WebSocket which was proposed by Michael Carter and first implemented with an API shim by Orbited. WebSocket is highly useful for Comet applications, and can be thought of as a web-safe TCP Socket.
Matt & Eric: HTML 5 contains some groundbreaking building blocks for programmers who think of the browser as an application canvas, but in so doing it over-reaches the realm of document semantics and extends into the realm of the DOM API -- another aspect of the ecosystem that needs attention, but not necessarily as part of the HTML spec. Our preference would be to see the HTML 5 spec confine itself to the enrichment and refinement of document semantics while leaving the behavioral APIs to be treated by other specifications.
In general, developers should be aware of the following HTML-related features provided by HTML5:
- Deprecation of presentational elements and attributes
- More semantic elements
- More input types and semantics
- Custom data attributes
Developers are seeing more attention paid to the DOM API aspects of HTML 5, and indeed some of these, if ultimately codified, will increase the depth of our toolkit in important ways. The early uptake by browser manufactures of a 2D drawing API (via the Canvas element) and the client-side storage APIs have generated a lot of interest already -- and that interest is directly related to browser manufactures having prioritized their implementations prior the spec being finalized. But there are a host of other important changes being proposed in the current draft, including:
- Iframe sandboxing
- "getElementsByClassName()" support
- "classList" API
- Audio/Video (via Audio/Video element) API
- Offline web apps API
- Editing (via contentEditable attribute) API
- Cross-document messaging API
- Server-sent events API
HTML 5 tries to tackle a lot of big problems, and it goes well beyond what we've listed above.
Andrew: Man, there's stuff in there for everyone. The "web storage" stuff (client-side database) is going to be huge - a number of sites are putting it to good use already. The new form controls (née Web Forms 2) have been in the spec since the very beginning and I still can't wait for them to get implemented. Server-sent events are going to make it possible to do pure "push" applications instead of relying on incessant Ajax polling or a brittle Comet connection.
I also like the custom data attributes, even though it's a minor feature compared to the ones I've listed.
Thomas: Next to to offline features (mostly the persistant storage), I find the VIDEO and AUDIO tags the most important addition, as there finally is a way to do it without the OBJECT and EMBED pain. Of course it will take a while until this is supported everywhere, but still this is a huge step into the right direction, plus all the standardization of informal standards should lead to general better browser behaviour. A hidden gem is the ability for web applications to register protocols and media types so they can become default applications, just like desktop apps (but there's a lot of hurdles to overcome here from a UI point of view, as Joe User doesn't understand what a 'protocol' or 'media type' is).
David: No HTML 5 feature is too noteworthy unless there's wide support for them all. Concepts may be worth emulating, but using the native version of a specific feature when few browsers support it means trouble. This is why we're not using querySelectorAll: the different implementations by browser vendors could present more browser-specific hacks than simply avoiding QSA all together.
Scott & Joel: The things that I find most exciting presently in HTML5 are those features that can be used right now, without requiring developers to build a completely different version of their app. The database and application-caching APIs are particularly interesting, because an app can realistically support both online- and offline-modes. They're also a huge boon to mobile web developers, because they provide a lot of leverage in dealing with incredibly slow and flaky mobile networks.
I'm also excited by the other HTML5 features, such as <canvas>, <audio>, and <video>, that unlock new functionality that currently requires plugins to support. These tags aren't yet universally supported by the major browsers, but as adoption spreads so will their use.
Dylan: Our goal is to always create things that fill-in the browser gaps. We hope that things we do become irrelevant over time (e.g. normalizing event systems or QuerySelectorAll). We're finding that in some cases, we get to remove code over time, but users of Dojo don't notice a difference as they can continue using the same API that will just wrap the native call when feasible.
Andrew: A "middleware" framework like Prototype - which takes ugly, inconsistent APIs and makes them uniform and whole - doesn't benefit much from the new HTML5 stuff. Some HTML5 features will make some tasks easier, but Prototype will still have to remember the "hard way" until the last of the non-HTML5 browsers is no longer supported. Bleh.
Prototype and script.aculo.us don't have long-term roadmaps, but I know I'll start thinking seriously about using a certain feature once at least two out of the four major browsers support it. Keep in mind HTML5 isn't going to be implemented all at once.
Thomas: Yes, they will evolve, and will gradually support those new features as browsers implement them. This is nothing new for the frameworks, though it's mostly bugs, not features that have to be addressed as new browser versions are released. Right now, for script.aculo.us, the biggest new "playground" will probably be the CANVAS element, and of course it can leverage everything we put into Prototype, e.g. the insertAdjacentHTML() DOM API is probably faster then how we do HTML insertions into the DOM now.
David: We think it's likely that we'll do what we've always done: abstract the API away from browser implementations and fix issues where they diverge. To the extent that we can develop solutions for older browsers to provide cross-browser stability we will, but in cases where we can't we'll provide functionality to detect that and deal with (or maybe fake it). Let's not forget that IE6 refuses to die. It'll be a long time before we can really count on these features.
As for a roadmap, we would imagine we'll take advantage of features that enable us to make a smaller, faster library first. So if we can build, say, a faster selector engine for browsers that support H5, we're more likely to focus there than on enabling features that only a few bleeding edge browsers support. Integrating the spec into our API will likely mean performance gains and byte savings, which are bigger wins for us in the short term until the more advanced features are more prevalent in the browser market.
Scott & Joel: With GWT we tend to focus on features that can be implemented across the major browsers, but we may provide different implementations depending on what browser a given user is running. To give a concrete example, I could easily see us providing a slightly abstract storage API that could use either Google Gears or HTML 5 persistent storage depending on what the user has. The nice thing with GWT is that end users only have to download the specific implementation their own browser supports because of how we compile all the possible permutations ahead of time.
Matt and Eric: The browser ecosystem allows for alternative models, and in fact many of these have been developed. Flash/Flex/AIR is a good example of an "alternative model" that thrives as part of (and in parallel to) the HTML/DOM/CSS web. Arguably, when you reach for your Facebook application on the iPhone instead of the mobile Facebook website you're voting for a new model there, as well. Thus far, no alternative model has managed to marry the low barrier to entry of the web with its inexpensive reach and accessibility.
Should we be "considering a different model" in the future? We'd argue that, as application developers, we're all considering alternatives every time we build a new application. If most apps today are web apps, that's simply an indication that the value proposition of the browser continues to be compelling. We think there's a lot of undiscovered value left in the browser and that evolving the specs intelligently (as with the ECMA 3.1 evolution) will continue to improve the foundation meaningfully.
Andrew: That's a tough one. Some people want browsers to interpret markup; some want browsers to draw pixels in a viewport. Depends on what sort of app you're building. It's not about replacing the DOM; it's about finding other models that complement the DOM so that you can pick the best tool for the job. I think CANVAS and SVG both have potential here.
David: How can we in the "immediate future"? Anything that H5 brings us that would allow us to change that model would only be available after years of availability. Further, that model is now well defined and understood and in use on billions of web pages. We don't think it's changing any time soon.
Scott & Joel: Oh, I don't think the current paradigm is anywhere near its limits. But it is evolving more rapidly and organically than ever.
On one side you have a lot of new energy being poured into making browsers better (Chrome with V8, Firefox with TraceMonkey, Safari with SquirrelFish Extreme, and of course IE8). No matter which browser you prefer, users will have a much more powerful platform for developers to build on.
At the same time, the tools that developers have available to target this platform get better every day. Perhaps unsurprisingly, I think GWT was pretty revolutionary when it launched. But we just put out GWT 1.6 a few weeks ago, and it's a much more compelling product than the original GWT, or even the GWT you could have used just a year ago. And you see the same thing across the board with other tools as the space matures.
So I think it's safe to say we have a lot of room to run here.
Browsers are free to support alternative script engines. As long as they implement the DOM APIs to spec, it doesn't really matter what scripting language is used. Some people -- including Douglas Crockford here at Yahoo -- have argued that a new language built with security in mind is necessary for the Web to take the next step.
To the extent that we will always have browsers who do things wrong, we'll need #1. To the extent that the API continues to suck, we need #2. And to the extent that the spec does not endeavor to provide rich functionality, we need #3.
We just don't see any of this changing any time soon.
Nice but IE doesn't like W3C very much and the mobile world is missed
Jose M. Arranz
Internet Explorer v8 lacks support of some basic W3C standards like W3C DOM Events and mobile browsers are a nightmare. I see HTML 5 adopted for very specific web "applications" and for selected browsers.
Sarah Howe Jul 06, 2015