- The website promises “This is the book for web designers, web developers, and front-end coders who want to get up to speed with HTML5 in 2012”. It isn’t.
- It is a healthy antidote to all the bullshit out there claiming that HTML5 cures cancer and brings about world peace
- At only $4.99, it’s very cheaply priced and you’ll probably learn something or, if not, you’ll have some useful antidote to the hype. So buy it!
Stevens’ book is not a really a tutorial. If you know nothing about the subject, I doubt whether this book would teach you enough to start coding HTML5. But for those of us who’ve been following the development of the language, it’s a great commentary on the good, bad and the ugly of HTML5.
If such a thing interests you I heartily recommend that you buy it although, as with any polemic, there are parts of it I disagree with.
For example, Stevens writes “There was—and is—no unifying vision of “HTML5”.” Now this is inaccurate. The unifying vision of HTML5 was to extend the Web without breaking it; evolution rather then revolution, with a set of design principles:
- Support Existing Content
- Degrade Gracefully
- Do not Reinvent the Wheel
- Pave the Cowpaths
- Evolution Not Revolution
- Solve Real Problems
- Priority of Constituencies
- Secure By Design
- Separation of Concerns
- DOM Consistency
- Well-defined Behavior
- Avoid Needless Complexity
- Handle Errors
- Media Independence
- Support World Languages
In his chapter on the structural elements, Stevens complains that the new markup elements are badly defined and hard to learn:
These are serious problems that hurt, rather than help, web standards. Markup should be lightweight, easy to learn, and easy to apply. It should not require mental gymnastics to try and work out what to use where.
Anything new is hard to learn. It’s not so long ago that we were still coming to grips with how to use HTML 4, and building up a canon of best practice as a community with efforts such as Dan Cederholm’s Simplequiz. The language has increased the number of elements by more than 30%, as well as gained many, many new APIs and become generally much more complex . People haven’t instantly understood all the new changes. I’m comfortable with that; change takes time to settle.
Stevens also suggests that the new elements are somehow tarnished because Hixie made them up before the Google research that analysed 1 billion web pages, and therefore suggests that aren’t useful. He quotes Hixie to back up his assertion:
Hixie: Me and other WHATWG contributors [added them], [in] 2004ish, because they were obvious elements to add after seeing how authors used HTML4. We later (late 2005 early 2006) did some objective research to find out what the top ten HTML classes were and it turned out that they basically exactly matched the elements we had added, which was convenient.
But, as Hixie says “they were obvious elements to add after seeing how authors used HTML4”. These weren’t just dreamed up out of nowhere – they were dreamed up out of real, but anecdotal, experience of what authors really did, which was then corroborated by objective research. This seems fine and reasonable to me, and doesn’t feel like the smoking gun that Stevens believes it is.
The author dislikes the names of the new structural elements (<header>, <aside> and <footer>) because, he says, they don’t closely match the way that designers would describe areas of the page: Header, Content, Sidebar and Footer. Those seem to me to be quite a good match, but Stevens doesn’t think so and prefers the ARIA roles banner, main, complementary and contentinfo, which to me feel more alien.
Stevens laments that multiple meanings of some elements:
In HTML4 a paragraph is a paragraph is a paragraph. In HTML5 an “article” is a forum post is a blog comment is a widget is a an actual article.
I disagree. We’ve all seen “paragraphs” that are not paragraphs at all, but merely sentence fragments – for example
<p>Products include:</p> <ul>...</ul>
Is “Products include” really a paragraph? Of course not; it’s merely that <p> is the best-fitting element to use. And so it is with the multiple uses of <article> in the spec. At least there are suggestions in the spec that may encourage some kind of conventions amongst developers.
Stevens continues “If an element has such broad meaning, how can it be more ‘semantic’”?” This is not a new problem with HTML5. In the HTML 4 spec is the ridiculous suggestion in the spec that the <dl> element is appropriate for marking up conversations on the grounds (I guess) of its default visual rendering in browsers. I agree that we need to keep HTML lightweight, so it will never be possible to capture every subtlety of meaning with a limited set of elements, but I strongly feel that HTML5 elements are much more tightly defined than HTML 4.
Lastly, Stevens sees no practical value to the HTML5 document outlining algorithm:
So user agents (screen readers in particular) will have very little incentive to ever use HTML5 outlines—the main point of these elements—as a means of navigation, given they’ll be (and already are) an utter mess.
For the last eight months, the largest screen reader on the market, JAWS, has supported HTML5 outlines (albeit buggily) so presumably they do see an incentive to use it.
I disagree with some of Stevens’ conclusions, particularly in his discusssion of the new semantics, but it’s solidly researched and lots of fun if you like hearing someone with strong opinions rant for a while (as I do). I enjoyed reading his book and, for the price, recommend that you have a look.