Review: HTML5 for Web Designers

While it went on sale back in May, A List Apart's first publication, HTML5 for Web Designers, only just began shipping. I have been eagerly awaiting my copy and it just arrived. I'm not normally compelled to write reviews of technical books I read, mainly because I don't read them all at once and they usually just lie around my apartment as an every-so-often technical resource (when Google turns up nothing). This book is different. It reads like much less of a verbose white paper — or HTML5 specification rather — and more like a refreshing one-sitter.

HTML5 for Web Designers - A Book Apart
At only 85 pages, this book is rather slim and handy for taking — and reading in its entirety — on my morning Caltrain commute to Notifo HQ.
The HTML5 spec is 900 pages and hard to read. HTML5 for Web Designers is 85 pages and fun to read. Easy choice.

What to Expect

This book is not a one-stop shop for all your HTML5-related needs. It's an introductory resource aimed at showing you a snippet of the new functionality contained within HTML5 and the reasoning behind it with a dabble of example code. Not much more than that. It scratches the surface — enough for you to know what you want to use to do something in your next project and point you in the right direction with how to get started and research more. That being said I was a little disappointed upon flipping through the pages of the book when it arrived. I wanted to see sections about things like geolocation, drag and drop, Web Storage, Web SQL Database, Web Workers, WebSockets and so on.

Instead I was greeted with this quote in the book:

The [JavaScript] APIs in HTML5 are very powerful. They are also completely over my head. I'll leave it to developers smarter than me to write about them. The APIs deserve their own separate book.

Fair enough. Those are rather technical subjects and this is an introductory book. I can live with that. In fact, the first chapters of the the book cleared up many misconceptions about what the HTML5 spec actually encompasses. Many people lump things together in the HTML5 buzzword. Web Storage isn't even in the HTML5 spec, but I had to read Mark Pilgrim's Dive Into HTML 5 to learn that nugget:

[Web Storage] was at one time part of the HTML5 specification proper, but was split out onto its own specification for uninteresting political reasons.

Author Jeremy Keith, whose DOM Scripting and Bulletproof Ajax books have been in my arsenal for several years, sets out to explain some of the more landmark structure and feature changes in HTML5 while keeping the book far from a boring technical read:

Suppose there's an evil bastard out there who hates the web and all who sail her. This person probably doesn't care that it's incredibly rude and stupid to embed an audio file that plays automatically. Thanks to the autoplay attribute, such malevolent ambitions can be realized

Doesn't quite read like an O'Reilly book. I like that.

Chapter Breakdown

HTML5 for Web Designers is separated into the following chapters. I took some notes while reading and will attempt to clean them up and present you with some broad takeaways for each. This is not a summary of the book and some sections are left out. I recommend you snatch a copy the book to get the bigger picture. I just want to share what I learned.
  • A Brief History of Markup
  • The Design of HTML5
  • Rich Media
  • Web Forms 2.0
  • Semantics
  • Using HTML5 Today

A Brief History of Markup The first two chapters setup the history of HTML and provide some good insight into the rather confusing space of HTML5. Keith begins all the way back in 1991 with Sir Tim Berners-Lee proposing the original HTML spec, which started at version 2.0. Mentions of the Internet Engineering Task Force, the World Wide Web Consortium (W3C) and the Web Hypertext Application Technology Working Group (WHATWG) intertwine with mentions of Web Apps 1.0, XHTML 1.0, HTML 4.01 and lots more specifications and version numbers. The current state of HTML5 emerges — the WHATWG and W3C HTML Working Group are both working on the HTML5 specification in a still-complicated manner.

The Design of HTML5 HTML5 is all about backwards compatibility — supporting existing content. Lots of emphasis on how changing existing user behavior is just about impossible. A key point of this chapter that sets the tone for the book starts with the description of the relatively simple HTML5 doctype and character encoding:

<!DOCTYPE html> <meta charset="UTF-8">

From that Keith ascertains that HTML5 places less importance on versions and more importance on backwards compatibility — browsers support features, not doctypes. Likewise, other facets of the syntax have been simplified. You no longer need to specify text/javascript or text/css for script or CSS inclusions, respectively.

HTML5 for Web Designers mentions how in the favor of backwards compatibility and supporting existing content (starting to see the trend here?) that certain elements are being marked as obsolete, not deprecated, in HTML5. These obsolete elements include frame, frameset, noframes, acronym, font, big, center, strike, bgcolor, cellspacing, cellpadding, valign and big. Meanwhile, certain elements like small, b, i and cite received an update in their meaning in regards to how each one bestows importance and semantics upon their contents. Keith also mentioned how the a element now officially supports wrapping multiple non-a elements in a single a element in HTML5, even though browsers have been able to do this for a while already.

The chapter ends on a brief mention about JavaScript APIs like drag and drop and UndoManager that HTML5 will document, but there's no diving deeper into that subject matter.

Rich Media Canvas, audio and video make their appearance in chapter 3. These elements bring native rich media support to the browser without the use of plug-ins like Flash or Silverlight, but they are not without their caveats. The canvas element lacks a DOM and as such is less accessible to screen readers unless used in certain, less advantageous manners. Aside from that (rather large) nitpick, canvas seems to hold much promise. It currently only has a 2D API, currently capable of JavaScript actions like strokes, fills, gradients, shadows, shapes and Bezier curves that can be run at any time. Keith suggests thinking about canvas as an environment for creating dynamic images.

Audio and video are easier to begin using right off the bat but it is quickly realized that browser limitations force developers to encode different versions of media as well as include fallback content to cover all the bases. Boolean attributes (not the same as Boolean values) are touched upon. Just think of them like how putting "checked" in an input checkbox changes its value, regardless of whether "checked" is set to anything. The audio element has several of these Boolean attributes: autoplay, loop, controls. The audio player is scriptable via calling functions like play() on the element. Meanwhile, the video element is both scriptable and styleable.

Web Forms 2.0 The fourth chapter has many sections introducing and showing off new elements and features for forms — perhaps the most interesting section for web application developers by far. And it is with that declaration that I point out the placeholder attribute for input field. If you've ever had to do something like this:

onfocus="if (this.value=='Search') this.value=' ';" onblur="if (this.value=='') this.value='Search';"

Then you'll immediately know what placeholder does. It replaces the need for that JS snippet — in supported browsers. This is where Jeremy takes the time to check whether an element supports that attribute. This is done many times in the chapter and reinforces the motif that working with HTML5 is more about feature detection rather than browser detection. This is touched on more in the last chapter.

Other elements discussed include:

  • autofocus
  • required — Boolean attribute for input fields (think form validation)
  • autocomplete — Boolean value to tell browsers whether or not they should automatically fill in forms if they have the data (for example, tell a credit card number text input field not to automatically fill)
  • datalist — hybrid between input and select. Provides a drop-down of items while typing text into an input or while focused, which users may use to click on the item they want.
  • many new input types: search, email, tel, url, range (slider!), spinner, date, datetime, datetime-local, time, month, week, color and pattern

And of course, there's a smattering of Keith's quips. In regards to how type="date" brings up a native calendar display:

Opera implements these input types using its patented ugly-stick technology.

And about using the pattern attribute (regular expression):

Most of the time, you'll never need to use the pattern attribute. On the occasions that you do, you have my sympathy.

Semantics Chapter 5 is the beefiest chapter in the short pamphlet-like book and with good reason; it discusses new structure changes in HTML5 with a focus on bridging the gap between machine-readable and human-readable markup. There's some talk of microformats and how they were an early attempt at web-based semantic markup and dataformats by utilizing present technologies, like simply adding particular class names to elements.

Several new elements are introduced again.

  • mark — like highlighting a certain snippet of content without attaching any semantic importance to it
  • time
  • meter — for measurements
  • progress — like meter but more for dynamically changing values. scriptable.

But the pieces that might take a second to grok are in the structure section of this chapter. While at first they may just seem like new elements to use in place of divs that you already use, they will provide web browsers (that support it) with "a completely new way of understanding your content." Using these elements isn't always as simple as say, replacing your <div id="header"> with <header>. These new semantic elements place importance on content rather than position and it is as such that Keith provided a few examples of how a footer element would make sense to mark up author information that is positioned inside of a sidebar.

  • section — used to group related content
  • header — container for a group of introductory or navigational aids. document can have multiple header elements. typical to use header within section.
  • footer — info about author of main content, links to related content and so on
  • aside — related content but separate from main content
  • nav — list of links for major navigational info and sitewide nav. typically used within header element.
  • article — self-contained related content designed for syndication. think blog posts

Last but not least was an explanation about content models and the new outlining algorithm. Inline elements are now known as text-level semantics, block level elements like lists, divs and paragraphs are grouping content, forms are their own content model, new structural elements listed above are sectioning content while images, audio, video and canvas are being referred to as embedded content.

Things get a bit trickier when talking about sectioning content and outlines:

In HTML5, each piece of sectioning content has its own self-contained outline. That means that you don't have to keep track of what heading level you should be using—you can just start from h1 each time

Each piece of sectioned content can have its own header element and other headings; several times on the same page. This means you don't have to many levels of headings to get the desired nesting. Use sections to divide it up and start each one as if it were a new page, if that makes sense. Then you can use the hgroup element to ensure that only the first heading listed contributes to the outline. An example use case would be having a website title heading and tagline within an hgroup inside of a header element.

I can't describe the concept as well as Jeremy did without going into lots of detail, so I'll leave it at that. Certain elements called sectioning roots are not subject to the outline algorithm: blockquote, td, fieldset. You can imagine how that works out.

Using HTML5 Today In short, you can't use everything you just learned right away and expect it to work in good chunk of modern (as of this writing) browsers. Instead, HTML5 for Web Designers enforces good practice by using tools like Modernizr to detect supported features in browsers and use new features where supported, gracefully degrading where not supported. You can start by updating to the new doctype and getting in the habit of using new semantic elements by changing the classes of your divs to section, header, aside and so on. When the time comes that HTML5 has better support in browsers, you can simply go back and switch to actually using those elements.

Other HTML5 Resources

While HTML5 for Web Designers is among the very first HTML5 books to hit shelves, several others from reputable publishers are coming later this summer. However, I will go out on a limb and say most will not be as brief and easy a read as HTML5 for Web Designers. After reading it though, I definitely want to learn more and feel like this book barely touched the tip of the iceberg.

Verdict

HTML5 for Web Designers - Layout
Lovely typography and whitespace galore

I give HTML5 for Web Designers 8.5 out of 10 Stammys. Oh and I just used the HTML5 meter tag on that rating, as mentioned in the book. The book is a well-designed quick and simple read, if a little too beginner-oriented. I would have liked to see more discussion about JavaScript browser APIs and some more in-depth examples along with included code on a website somewhere. At 18 + shipping for a slim book, you might double-think about whether HTML5 for Web Designers is actually worth it for you.

On an related note, do you buy technical books anymore or rely on the Internet? I used to be an avid consumer/reader of technical reference books and bought at least one every other month for years. Then I started realizing that they would remain on my bookshelf — and become outdated — as I would simply Google for whatever I needed.

What are your thoughts on HTML5? How about the HTML5 buzzword collective.. CSS3 and related JS APIs? What do you think about this book?

Disclosure: I was not given an advance press copy as other bloggers have been. I bought this myself and decided to write about it on my own. I have no affiliation with the author or publisher. If you read this far, grats! Leave a comment saying something smart about anything web dev/HTML5/etc related and if I like your comment I will send you the book I just reviewed.

Twitter · Mastodon · Subscribe (RSS)

Paul Stamatiou is a designer who codes. He's the Co-Founder of Rewind AI, previously designed at Twitter for 9 years, and has been writing here for 18 years.