Review: The Truth About HTML5 For Web Designers

by .

The Truth About HTML5 For Web Designers is an ebook self-published by Australian developer Luke Stevens.

TL;DR:

  • 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!

cover image

Longer review

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
  • Accessibility

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.

Conclusion

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.

10 Responses on the article “Review: The Truth About HTML5 For Web Designers”

dj says

Based upon what (and how) you wrote, I’m not actually certain why you would still recommend a person spend his money on such an esoteric “B” novel. [Except that a year or so reading this blog has taught me that you "doctors" often bend yourself into pretzels trying not to offend anyone (a good thing, I guess.)]

It seems obvious, when you can come back with such a lengthy list of “unifying principles” at the ready, that the guy actually made NO effort to contact any of the WHATWG for real research or truth. All of what you quoted sounds like some wannabe coder hoping for a shortcut to some bucks by hyping a “what your doctor doesn’t want you to know”, “what your government is hiding” rag, using third and fourth hand information from an internet search mixed with his own opinion.

I say “based upon what you wrote” because in this instance I’ll take your word for it, I certainly don’t intend to reinforce such activity by throwing money at. We all can use a search engine – and since when is the personal opinion of someone “not in the know” worth money – we get that for free everywhere.

However, if the guy claimed that the WHATWG’s written spec’s often read like some double-talking politician-lawyer working for the IRS; then, that would be the truth. (Opinion still, but truth none-the-less and we don’t need to spend bucks to learn that.)

Bruce Lawson says

dj

I think Stevens has done significant research, asking the WHATWG for information, dredging it out of the archives. It’s just that he and I draw different conclusions from that research.

But I recommend his book as I think it’s important for people to get all sides of the argument, and Stevens is well-informed and has thought deeply about the issues, unlike many of the clowns writing books and articles.

John Allsopp says

I put my name to the book a little, writing a forward for it, so I thought I might add a little as to why I did that.

When Luke first asked me to take alook, I thought it would be just aother book on HTML5. Perhaps worthwhile, but with quite a few out there, not least of them Bruce and Remy’s, it was more out of politeness than with any great expectation.

As Bruce himself said, quoting me, way back when, HTML5 is a mess

http://www.brucelawson.co.uk/2009/html-5-is-a-mess/

Many of us have bbeen critical of many aspects of HTML5. Often in 140 characters, occasionally in longer blog posts.

I quickly realised Luke had written an extended essay on the messiness of HTML5. And its good parts.

But why I was so enthuiastic about it is that it is something very rare in our field – a critique of our techologies and practices.

As what we do with web tech becomes increasingly sophisticated, we need to move away from a purely “what and how” toward a “why, why not, what else” approach. Luke’s book focusses on those as much as the what and how.

I look forward to other books like this. Ones that further our understanding of our craft/profession/practice. Ones which take a critical reasoned, evidence based approach, and and which are willing to take a position on what are at times important issues.

Unlike almost anyone in these conversations, as Bruce observes, Luke’s been willing to do a lot of research, and articulate well his position on.

I look forward to more liek this in our field, and whether this particular book lives longin our memories, or like most work in our field slowly fades over time, I think it is a landmark publication in our evolution toward a sophistcated group of practitioners.

Nick groenewegen says

But I recommend his book as I think it’s important for people to get all sides of the argument

As what we do with web tech becomes increasingly sophisticated, we need to move away from a purely “what and how” toward a “why, why not, what else” approach. Luke’s book focusses on those as much as the what and how.

Amen to both these quotes!

In the long run i believe that all these different insights, positive or negative can only contribute to the completeness of the specification. Hell, small idea’s of critics might even make you think twice or start of your brain again on a subject you might thought complete.

Luke Stevens says

Awesome, thanks for the review Bruce! :)

A few comments in response if I may:

- Yeah, it’s not a tutorial, but hopefully it’s the kind of book which gets people up to speed with the state of affairs in HTML5 before the numerous, often wrong tutorials out there send them the wrong way.

- My comment re the lack of a unifying vision of HTML5 makes more sense in its original context:

Web standards are incredibly haphazard. There was — and is — no unifying vision of “HTML5”. It was just a bunch of separate specifications bundled up and given the name “HTML5”, and those specifications only came about as a reaction to the W3C’s failures.

I wasn’t commenting on the specification’s supposed design principles, but the organic way in which “HTML5″ came to be, particularly that it didn’t start with anyone sitting down and saying “Jolly good work on HTML4 chaps, now let’s get cracking on HTML5 shall we, and this is what it will look like!” :)

- My comments on the new structural elements wasn’t that they’re bad because they’re new, and therefore hard to learn. My comments on the new structural elements is that they’re a confusing, poorly specified, poorly communicated, and poorly understood group of elements thrown into the spec on the whim of seemingly one guy who seems to have forgotten their purpose and *that* is what makes them hard to learn :) That the community has almost entirely got them wrong — essentially forking the spec, as I argue — is testament to the faults in the specification, not merely their newness.

You write:

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.

This certainly would be fine and reasonable, were it true, but I did the research, and it’s not :)

I don’t think you’ve understood the crux of my argument. Hickson added in elements that *sounded* familiar (header, footer, article), but then gave them definitions that most certainly did not reflect what authors really did, either anecdotaly, or in the research. For example, authors weren’t using header and footer for each and every comment on a page. They weren’t using article for comments (or forum posts, or widgets). They weren’t using section to outline a page. And they weren’t using aside for sidebars. For Hickson to claim that the spec here is based on ‘objective research’ seems disingenuous to me, and his plainly wrong suggestion that this is just what authors were already doing has created the huge mess we now have on our hands.

As I write in the book:

What happens when you take terms people use, redefine how they should be used (and even give them multiple uses), and then tell those same people not to worry because the terms are exactly what they’re already using? You put them on a one-way trip to confusion city.

This is a really important point, and I hope it’s one the HTML5 Doctors take on board, because the myth keeps getting repeated, but it’s wrong (e.g. in April: http://html5doctor.com/lets-talk-about-semantics/ ), and it has resulted in essentially the forking of the spec. There’s the “community” fork where people just keep doing what they’ve been doing, and the “actual specification” fork which suggests quite a different implementation. One or the other has to change, and I’d love to see HTML5doctor.com explore this issue some more :)

Re ARIA roles, I agree the names are a bit more alien, but their use is far more in line with what authors actually do.

- As for HTML5 document outlines, due to the semantic mess outlined above, these are (as I argue), dead on arrival. The JAWS support — such as it is (!) — sounds like a train wreck, and is the kind of predictable mess that happens when there’s essentially two distinct ways to outline a page that we’re suppose to implement at the same time, but the poor screen reader can’t tell one from the other. HTML5 outlining violates a number of the design principles you mention in the review and, frankly, the way it has been specified stinks. As I write in the paragraph following the one quoted:

It’s sad, isn’t it? Tim Berners-Lee’s 1991 wish for sectioning finally makes it into a shipping HTML spec (after the aborted XHTML 2.0 project), only to be misunderstood and abused two decades later.

Again, I really hope the HTML5 Doctors can explore this some more. If any of the Doctors are reading this and want to check out the book, just hit me up on Twitter :)

Finally, I just wanted to mention that the book isn’t cover to cover semantics :) There’s also a fairly extensive discussion on Flash & HTML5′s Canvas, the state of audio and video in HTML5, and more.

Thanks again for the review. And on to the comments….

Luke Stevens says

@dj, If I wanted a “shortcut to some bucks”, I can assure you that self-publishing an ebook for $4.99 after hundreds of hours of work is not a path I would have taken ;)

@John, Thanks so much, you are too kind sir! ;)

@Nick, Cool, let me know what you think of the book if you get a chance to check it out! :)

And if anyone else wants to say hi, I’m @lukestevens on Twitter :)

Simon Cox says

I have read this and am rereading it again. The arguments Luke makes about the new tags are solid and I like his suggestions for an existing alternative – Aria – and am going to give it a go on the next few projects to see what it throws up.

Good book and well worth the price – also like his ranty humorous style.

vbwyrde says

I am about 15 years in as an asp / asp.net developer for a mid-sized corporation. We’re starting now to look into HTML5. I for one am very happy to have run into this article and the book. I have a feeling it will save me from the condition of being confused-as-hell-without-realizing-it-until-its-far-too-late. So thanks in advance. I look forward to the ranty humor.

Huynh Hieu says

thanks for info, but how to load data site before load html5 code?

Scott Marcus says

As an IT trainer for 20 years, I’ve always felt it appropriate to give a bit of the HTML back-story when I teach X/HTML because, to new developers and designers learning HTML, XHTML and CSS at the same time, from scratch, it can be confusing as to why HTML 4.01 and XHTML 1.0 Transitional has presentational elements (e.g. FONT), but we pro’s shudder at their use in favor of CSS. Students need to have context for why we did what we did and why we now do what we do.

I’ve read many books, articles and blogs that discuss the evolution of HTML5, but Luke’s book does an excellent job at conveying the history and evolution of HTML5 and it does so warts and all.

Luke’s book made me understand that there is more than just a little animosity between WHATWG and the W3C and that this has and will continue to have a real impact on where we are and where we are going. It reminded me of the same animosity that existed between Tim Berners-Lee and Marc Andreessen, when Netscape was in search of a body to standardize JavaScript (does anyone really think that the European Computer Manufacturer’s Association was the first or best choice for this?). The point being that understanding how we got where we are can be just as important, if not more important than understanding what we’ve been given.

I’ve read Bruce and Remy’s book (both editions) and like it because it does a nice job documenting what’s in HTML5 and how to use those elements according to the spec.

I’ve most recently read Luke’s book (2nd edition: paperback) and must say, as someone with over 20 years experience with HTML, XML, XHTML, CSS, JavaScript, etc., who is now getting their head around HTML5, this book was eye-opening, to say the very least.

Yes, there are some things in the book that I think will become non-issues as IE8 fades off into oblivion and browser vendors decide what they will and won’t support. We all have different audiences to support and in my world that still includes IE8 users who may not have JavaScript turned on. But, the fact is that the only support the HTML5 Document Outlining algorithm has right now (01/2014) is not reliable in the one screen reader that uses it.

If you accept that the purpose of the sectioning elements is to build a proper HTML5 document outline and you accept the fact that the use of these elements doesn’t affect SEO, then the decision to use them or not MUST be based solely on whether or not the HTML5 Document Outline is going to be supported. So far, it doesn’t look like that’s going to be the case, which means that we must stick with H1 to H6 elements to build document outlines that are and have been usable by visually impaired users.

Now, if you couple this with the fact that a decision to use a particular H1-H6 within the new sectioning elements becomes meaningless to the HTML5 document outline (as their actual level will be dictated by the amount of section nesting going on), you find yourself stuck in “A Tale of Two Outlines” – - one that works now and most likely for the forseeable future (H1-H6) and one that doesn’t (HTML5 sectioning elements).

With regard to Hixie’s creation of the sectioning elements, in my opinion whether the research came first or second is largely moot. The undeniable fact is that he has indicated that these elements are a good fit because it’s the terms that were already being used. This is important – I think everyone will agree that the INTENTION for these elements was to specify formal names for forked names being used in the cowpath. The FACT, however, is that while the names may match what developers were using in the cowpath, the way these new elements are supposed to work is NOT the way the forked names on the cowpath were being used. This cannot seriously be considered “Paving a cowpath”, which is one of HTML5′s stated design principles.

My personal feeling is that, today, in early 2014, Luke’s book is a MUST-READ because it addresses the downs and ups of using HTML5, today. No one has a crystal ball and can forsee where HTML5 or HTML (the living standard) will take us and it may be that Luke’s book is still relevant for some time, but right now, it most certainly is!

Join the discussion.

Some HTML is ok

You can use these tags:
<a href="" title="">
<abbr title="">
<b>
<blockquote cite="">
<cite>
<del datetime="">
<em>
<i>
<q cite="">
<strong>

You can also use <code>, and remember to use &lt; and &gt; for brackets.