Wednesday, June 9th, 2010

HTML5: Deja Vu on Ajax

Category: Editorial, HTML

What does Open Web mean?

What does Ajax mean? Is it AJAX or Ajax?

Remember those discussions? We had the arguments … the purists who would shout and scream if you said something was Ajax and didn’t use XHR with async mode + XML as the format. Ajax beat our AJAX and became the new term for DHTML and the term that meant “all of the cool shizzle that browsers and JS library authors are now doing!”

The new king on the hill is “HTML5” which has taken that exact mantle. One extreme view is that the term is marketing drivel. The other is that it should ONLY be used to mean the W3C version of the HTML5 core specification.

Brad Neuberg enjoys thinking about these things and has put together some thoughts in two posts: Why I’m Going to Keep Calling it HTML5 and HTML5 Defined! It’s Not Just a Marketing Term.

I really like how Brad goes deeper on HTML5. It is far too confusing to know what capabilities are in browsers, what specs they are in, and what really matters… what can I use as a Web developer.

Brad takes apart the various specs and APIs:

Going deeper, I’ve broken these down into separate areas:

  • “HTML5 Strict” – Things that are strictly inside the W3C’s HTML5 spec.
  • “Referenced by HTML5” – Things that are referenced by the HTML5 spec and which can optionally be parsed into the DOM and displayed.
  • “Broken out of HTML5” – Things that used to be part of HTML5 or its older iterations, called Web Applications and Web Forms.
  • “HTML5 Family of Technologies” – Extended set of technologies not strictly part of HTML5 spec or referenced but likely to be used in conjunction with HTML5.
  • “HTML5++” – More experimental technologies pushing the web forward that are not part of the HTML5 spec at all; may or may not see broader adoption.

One small note; there are actually two HTML5 specs, one maintained by the W3C and the other maintained by the WhatWG.

You need to understand that HTML5 began as a revolution to the established order, initiated by the WhatWG. A peace of sorts developed over the years, with the upstart “Web Applications” and “Web Forms” specs brought in-house to the W3C under the moniker HTML5. Over time I’m assuming that the W3C spec, when Final Call has happened, will be the canonical spec.

To simplify things below, I’m only referencing the W3C HTML5 spec for now. Here’s how I would break things down based on what I said above; if you think something should be somewhere else or things get moved around email me and I’ll update this (Last Updated: June 7th, 2010). If you want to know the state of where these technologies are implemented see; if you want your code to detect what is available see Mark Pilgrim’s book for details.

“HTML5 Strict”: Strictly Inside the W3C’s HTML5 Spec
  • HTML5 Doctype: <!doctype html>
  • HTML5 parsing
  • XHTML5 serialization
  • Cleaning up edge cases of existing web content for greater compatibility
  • New semantic, behavior, and application tags: section, nav, article, aside, hgroup, header, footer, address, figure, figcaption, time, code, var, samp, kbd, output, progress, meter, details, summary, command, menu
  • Being able to nest H1, H2, etc. arbitrarily
  • Sandbox attribute on iframes
  • Video tag, API and events
  • Audio tag, API, and events
  • New form input types: telephone, search, url, e-mail, date, time, month, week, number, range, color
  • New form abilities: multiple file upload; placeholder text; directing focus on initial page load; constraint validation by input type and properties
  • New link rel types: alternate, archives, author, bookmark, external, help, icon, license, nofollow, noreferrer, pingback, prefetch, search, sidebar, tag, index, up, first, last, next, prev
  • data-* attributes for SCRIPT tags
  • Offline Web applications
  • contenteditable for editing
  • Drag and Drop
  • UndoManager for consistent undos
  • Parsing empty and unknown tags into the DOM: <foobar />
  • async attribute on SCRIPT tags
  • PUT and DELETE methods for form submission
  • Deprecated elements: acronym, applet, basefont, big, center, dir, font, frame, frameset, isindex, noframes, s, strike, tt, u

“Referenced by HTML5”: Referenced from W3C HTML5 spec, including how to parse into an HTML5 DOM; HTML5 parsing engines can optionally include these in DOM and display them
  • MathML
  • SVG

“Broken Out of HTML5”: Used to be inside of HTML5, Web Applications, or Web Forms specifications
  • Web Sockets
  • Local Persistent Storage (localStorage and sessionStorage)
  • SQL Storage (in contention versus IndexDB)
  • DataGrid
  • Specific HTML5 Video codec: H.264, Ogg/Theora, WebM (contention between video codecs)
  • Specific HTML5 Audio codec
  • Device element
  • Ping attribute
  • Timed track model for media elements
  • Canvas
  • Microdata and Microdata Vocabularies (some level of contention versus RDFa and Microformats)
  • Cross-document messaging
  • Channel messaging
  • W3C XMLHttpRequest specification
  • Server-Sent Events
  • Ajax Session History
  • MIME type and Protocol handler registration
  • P2P connections

“HTML5 Family of Technologies”: Extended set of technologies not strictly part of HTML5 spec or referenced but likely to be used in conjunction with HTML5
  • CSS3
    • Flex Box Layout
    • Multi-Column Layout
    • Animations
    • Transforms (2D and 3D)
    • Transitions
    • Masking and Effects (rounded corners, shadows, etc.)
    • Gradients
    • CSS3 Selectors
    • Media Queries
  • Web Fonts – CSS 2.1 @font-face + OpenType/WOFF (slight contention for OpenType vs. WOFF)
  • W3C Geolocation
  • Metadata – RDFa, Microformats (Some level of contention vs. Microdata)
  • Web workers
  • ARIA
  • EcmaScript 5
  • Faster JavaScript
  • CSS styling of new HTML5 input types (color, range, etc.)
  • IndexDB (in contention versus SQL Storage)
  • querySelector/querySelectorAll
  • getElementsByClassName
  • GPU acceleration of HTML, Canvas, SVG, and CSS3 Animations/Transitions/Transforms
“HTML5++”: More experimental technologies pushing the web forward; may or may not see broader adoption
  • WebGL
  • O3D
  • Firefox Audio APIs
  • XBL 2.0

We can argue about which term to use when, but I am much more excited about is explaining the capabilities and working together on nice stacks so we can build killer applications on the Web platform in a productive manner.

Check out a nice info graphic on all things HTML5:

Posted by Dion Almaer at 5:10 am

4 rating from 3 votes


Comments feed TrackBack URI

I think there are a few too many HTML5++ technologies underway right now. Browser vendors seem unable to keep up, and for us lowly developers this is especially true. There is way too much overlap between some of these technologies, and that demonstrates that there isn’t a cohesive vision. For example, we have 5 “standard” ways of storing “stuff” locally: cookies, localStorage, SQL storage, IndexDB, offline app cache. I think with a little more forethought that could have been fewer technologies (localStorage and IndexDB are almost identical and should have been one technology, SQL storage and offline app cache could have been layers on top of that). The same holds true of the various ways of doing graphics (canvas / SVG / webGL / CSS borders, gradients and transforms). CSS transforms are wholly superfluous (they’re just an apple hack to avoid hardware-accelerating the DOM API), and canvas is just plain weird (the more you think about the goals of that API, the less sense it makes).
The browser is rapidly becoming a hodge-podge of mismatched API’s, and it wasn’t all that clean to begin with. We should all be thinking about which of these technologies should be lifted up into toolkit-land, and which ones should be in the browser core.

Comment by Joeri — June 9, 2010

Count me as one of those that is sick and tired of the “HTML5” marketing term. Most of the so-called HTML5 demos are not HTML5 at all but just javascript or javascript+CSS3 demos. The term HTML5 is already more abused than Ajax ever was. At least with most things called Ajax they are often related with the notion of requesting/displaying new data without reloading the current page. With HTML5 we often get things that have nothing to do with HTML at all. Most of the blame for this term being misused so badly are on the industry websites just being lazy and not reporting things correctly. This is sad because there are lots of cool things coming our way because of CSS3 but it never gets the credit because people are lumping it into HTML5 for some stupid reason.

Comment by travisalmand — June 9, 2010

@travisalmand – You are definitely right about the CSS3 stuff, but believe it or not, there’s a lot of JavaScript APIs in HTML5. Some of it has been moved to separate specs, but a great deal of it at least originated in WHATWG under the HTML5 name.
@Joeri – I think there are two major causes to the hodgepodge problem:
1. HTML was designed standalone. As other technologies were added they were done by separate groups, and also done assuming that they might not be available. For example, trying to have graceful degradation for no javascript or css support. This is important, but at the same time, makes it much more difficult to be cohesive.
2. HTML and CSS (and to a lesser extent JS) were designed to be very high level. There is no api to handle the low level painting or layout of elements. I think that has been a boon to its explosive growth, but now that we want to do low level things it is difficult. As a result, we keep having to add more high level solutions tailored to specific use cases. This can create a lot of overlap.
I agree its a problem, but I don’t really know the best solution. I think the hodgepodge is probably the best we can do, and hope that some good frameworks make it nicer to use. Sure we could say start over with something more cohesive (I would actually like this), but I think aside from that, it would be hard to do. The start from scratch thing could happen someday, but I think it might not be feasible right now. Maybe as a backlash to HTML5? ;)

Comment by genericallyloud — June 9, 2010

@genericallyloud: I don’t buy that it’s just the way it is. There’s quite a small group of people working on this stuff. If they just talked to each other more and found more ways to cooperate and merge technologies, things could be better. Currently there isn’t even enough social cohesion to decide on a proper name for things.

Comment by Joeri — June 9, 2010

Not agreeing with this article at all. HTML5 is exactly what the specs says it is. Non-developers and fanboys started with the whole HTML5 is everything hype – should the developers condone that now? Also the charts above are a bit misleading – for example it states that HTML5 is at the moment more accepted than Flash (because Flash is a plugin and not supported in iPad/iPhone). Comparing how many PCs/devices in total run Flash today to how many support HTML5 is a joke – I’d say at the moment Flash wins by many many zeros. Also efficiency is a thing of comparing apples and oranges – anybody tried animating vector graphics (SVG) with JS?

Comment by allmandring — June 9, 2010

TRWTF is that graphic. Focus are showing that they ‘get’ HTML5 and Flash etc., but they show their graphic as a full-page JPG. And if they’re going to make it in PhotoShop, why can’t they design it better? Small, grey text is a really bad idea for reading on screen. And can anyone tell the difference between the “not supported” and “support unknown” circles in the compatibility chart? Some serious form over function going on here.

Comment by Skilldrick — June 9, 2010

@Joeri – I think there’s room for improvement, certainly, but assuming a high level of backwards compatibility, I think that the ship has sailed for a really elegant cohesive solution. Let’s look purely at your graphics example: canvas2D, SVG, css, and webGL. There is overlap, certainly, but none of them can do the whole stack. I certainly wouldn’t want to have to remove any of them. If you think arbitrary 2D graphics are pointless then you’ll find a lot of people willing to argue with you. As for CSS transforms – I think some of that stuff may go a little too far, but it makes a lot of sense when considering the way we already work with HTML. Is rotating 30 degrees so different from floating left, or scaling an element so different from setting the height and width?
No, I think what makes HTML5 clunky is that it has been altered and bandaged so radically from what it started from that it doesn’t have the feeling of being *designed* as much as slapped together. I look at it like a piece of software. We keep adding features but can’t do any refactoring so we’ve built up a lot of technical debt.
I like the way that JavaScript is going with Harmony. Some new features, some cleanup, not a kitchen sink, but definitely an improvement. It has a plan for deprecation and moving forward.
When HTML5 started, it seemed like a good idea. Nail down browser behavior and specify it in detail to make browser compatibility higher. Add some much needed features that were already in browsers.
I think what went off the rails was the million extra features without the willingness to just say ok HTML is pretty good, but lets step back and see how we can make the next step after this better and not just tack things on. We’ll need to break backwards compatibility a little, but let’s get the whole platform working, maybe even have a plugin reference implementation sort of like what Google Gears was doing. I just think that’s a little idealistic to expect from standards bodies, not to mention a big gamble considering it means nothing unless the browser vendors are willing to implement it. Look at what happened with XHTML2.
Something will happen one of these days. I can’t imagine we’ll still be writing HTML 25 years from now without some kind of a reset or replacement. I just hope that if there’s a replacement its as open as the current web stack.

Comment by genericallyloud — June 9, 2010

Good point about css transforms, what I really meant as superfluous are css animations. That stuff belongs in javascript.
Personally, I’ve mostly stopped writing HTML. I write javascript, I build components, and I tie those components together with code. (I’m using Ext and starting to use the Ext designer.) My app has one simple HTML page that does nothing but bootstrap the rest of the code. Web app development, ironically, is moving away from HTML at the dawn of HTML5. The DOM is the future, for better or worse.

Comment by Joeri — June 9, 2010

@genericallyloud – Actually I would disagree about the Javascript APIs in HTML5. I do not really consider those part of HTML5 since they are Javascript APIs. Everybody involved may agree to write them up in the HTML5 spec and implement them in the HTML5 timeframe but that doesn’t make them HTML5. HTML is a markup language, nothing more nothing less. Attributing a Javascript API to it leads back to the same problem that start this discussion, the continuing habit of calling new web technologies HTML5. I think it’s good that some of the APIs have been removed to be their own spec and any of the rest should be treated the same. I wouldn’t want Javascript APIs held up by the slow progress of HTML5.
@Joeri – I agree about the new CSS3 stuff. Transforms are fine since that is styling an element on the page. It’s the animations that I don’t care for and I think that for the same reason, that’s javascript functionality.

Comment by travisalmand — June 10, 2010

Some of the features you might think are CSS3 are from CSS2. It’s very hard (and useless) for developers to know what features, that all browses are thankfully supporting now, belong to a particular spec.

Although ‘open web technologies’ would be more correct, big companies started using ‘HTML5’ because of the way that developers and bloggers were referring to these technologies, not the other way around.

Comment by ernestdelgado — June 10, 2010

Another thing worth pointing out in this conversation is that the canvas 2D rendering context (which is essentially everything that makes the canvas tag worthwhile) is not in the w3c html5 spec. It was broken out into a separate spec.
And yet canvas is always one of the first things people associate with html5.
Yet another reason why clarifying features by what spec they live is not a sustainable enterprise. :)

Comment by PaulIrish — June 10, 2010

@travisalmand – Whether you want it to be considered part of HTML5 or not, the JavaScript APIs where created out of the HTML5 spec and so I think it is perfectly acceptable to label them under HTML5. I’ll be honest, though, I agree with the sentiment. A lot of what gets talked about as HTML5 has nothing to do with the actual markup. That said, I think that a word or phrase IS needed. I thought open web was going to stick too, but if it had to be something else, I don’t think HTML5 is that bad. After all, I really think it has been a major catalyst. WHATWG is basically run by browser makers cooperating to take the next step. CSS3 and SVG have been around for how long? It took WHATWG and some serious get it done attitude to turn the boat around.
You can criticize the result of the effort (I know I have), or the moniker, but if it wasn’t for the people behind HTML5, we wouldn’t have nearly so much to talk about or look forward to.

Comment by genericallyloud — June 10, 2010

Leave a comment

You must be logged in to post a comment.