HTML5 for Web Designers, written by Jeremy Keith, is the first book to be published under the A Book Apart brand, founded by Mandy Brown, Jason Santa Maria, and Jeffrey Zeldman.

When the book first landed on my doorstep, I was a bit let down by its meagre length of around 85 pages. I have to be honest, however, and admit I had not done my research before its arrival. From the book’s inception, the publishers stated that they intended to produce something to fill the gap between a blog post and book, something that people would be able to pick up, read quickly, and start implementing straight away.

So I set aside my disappointment and started reading this beautifully crafted book.

After reading through it, my opinion has changed. I realise exactly what A Book Apart were aiming to create when they decided on a short format for the series. HTML5 for Designers is split up into six bite-size chapters:

1. Chapter One: a brief history of markup
2. Chapter Two: the design of HTML5
3. Chapter Three: rich media
4. Chapter Four: web forms 2.0
5. Chapter Five: semantics
6. Chapter Six: using HTML5 today

To give you some insight each chapter’s topics, I’ve described them each briefly.

Chapter One

The first chapter lays out the foundations of the book and explains how, as a community, we arrived at the latest iteration of our favorite markup language, HTML5. Keith discusses how HTML was born, the ill-fated transition from HTML to XML (which never happened), the suggestion of XHTML2, and why we write “HTML5″ instead of “HTML 5″.

You might be tempted to skip straight to the second chapter, but I firmly believe that you should read this. It’s vital material, and you’ll almost certainly learn something. (I sure did!)

Chapter Two

Chapter two discusses how to convert web pages from XHTML 1 to HTML5. It also touches on elements that changed in HTML5 and some elements that are absent from the specification.

Chapter Three

In chapter three, the book delves into the realms of rich media and what it means for designers and developers. Keith hints that this chapter could have a whole book dedicated to it (perhaps hinting at an upcoming A Book Apart title?). He does a good job describing the possibilities of <canvas> and showing a few examples of its capabilities. Although some readers may wish for more depth, this book is of course written for designers, so detail is kept to a minimum.

Keith goes on to explain the possibilities of the <audio> and <video> elements, something which many argue will change the way we work with the web. Keith gives great examples on how to introduce these elements into your client work with various fallback options for browsers that lag behind.

Chapter Four

In chapter one, it’s explained that HTML5 started life as Web Apps 1.0 and Web Forms 2.0, which were later merged. So as one might imagine, Web Forms were destined to become an integral part of the HTML5 specification.

Chapter four covers the new elements and attributes for use in forms, including placeholder, required, autocomplete, datalist, new input types, sliders/spinners, and dates and times.

Chapter Five

Chapter five covers semantics (although I feel that this should have been one of the first chapters in the book). Elements discussed include <mark>, <time>, <meter>, and <progress>, as well as the usual structural elements that get used in nearly every site.

Chapter Six

Finally, chapter six discusses the most important question about HTML5: Can we use it today? I trust, as you are on this website, that you will already know the answer to that question.

My opinion of HTML5 for Web Designers

After finishing this book, I discovered that it is in fact quite a gem for anyone starting on their HTML5 journey.

There are undoubtedly areas that could have been expanded further, but the limitations imposed by the authors meant merciless fat-trimming. This is the type of book that you would be happy to keep on your desk as a quick reference manual, a shortcut before diving into the full HTML5 specification.

I would definitely recommend buying this book if you haven’t already. It’s true that great things come in small packages!

Buy the book directly from A Book Apart

Share and Save:

Reviewing HTML5 for Web Designers originally appeared on HTML5 Doctor on July 27, 2010.

Over the last few weeks, we’ve been working on something a little special here at the HTML5 Doctor.

You’re obviously here because you’re interested in HTML5. You might even be here because the thought of reading the HTML5 spec on the W3C site gives you nightmares. Well, fear not, for you shall be able to sleep easy once again! We’ve just launched the HTML5 glossary.

The purpose of the glossary is simple: we’re going to give you a breakdown of all the elements within the spec in clear, bite-sized chunks.

From the screenshot above, you can see that we’ve laid out the page to be as clear as possible (using HTML5, of course). At the top of the page is an alphabetised list of links to individual sections of the glossary. The rest of the page is the list of elements and their descriptions.

I’ve labeled the key points of each entry in the above screenshot:

1. Links labeled “Our Prognosis” refer to an article that one of the Doctors has previously published.
2. Each entry contains a brief description of what the element represents and its proper (and possibly improper) uses.
3. We always include a link to the element’s full description in the official HTML5 spec.
4. Code snippets show contextual examples of the element in an HTML document (shown in the screenshot below).

Not every element has a code snippet and “prognosis” link, but we’ll be doing out best to flesh out the glossary with some more examples and elements in the coming weeks.

Be sure to add the glossary to your list of HTML5 resources!

Got a suggestion to help us improve the glossary? Request a missing element or report a problem by leaving a comment below, or head over to the contact page and send us an email.

Share and Save:

HTML5 Doctor Glossary originally appeared on HTML5 Doctor on November 19, 2009.

The address element has been around since the HTML3 spec was drafted in 1995, and it continues to survive in the latest drafts of HTML5. But nearly fifteen years after its creation, it’s still causing confusion among developers. So how should we be using address in our documents?

The right way

Let’s take a quick look at the spec:

The address element provides contact information for a document or part of a document. Information provided by address may include the names of the document’s maintainers, links to the maintainers’ Web pages, e-mail addresses for feedback, postal addresses, phone numbers, and so on. The address element is not appropriate for all postal and e-mail addresses; it should be reserved for providing such information about the contact people for the document.

If we follow the above advice, we could do something like this:

The HTML5 Doctor is run by the following group of volunteers:
<address>
<a href="http://html5doctor.com/author/jacko">Jack Osborne</a>,
<a href="http://html5doctor.com/author/richc">Rich Clark</a>,
<a href="http://html5doctor.com/author/miker">Mike Robinson</a>,
<a href="http://html5doctor.com/author/toml">Tom Leadbetter</a>,
<a href="http://html5doctor.com/author/brucel">Bruce Lawson</a>,
<a href="http://html5doctor.com/author/remys">Remy Sharp</a>
</address>

Here’s another example that we’ve implemented on this very site:

<footer>
<div class="vcard"> by
<address class="author">
<em class="fn"><a title="Posts by Jack Osborne" href="#">Jack Osborne</a></em>
</address> on
<time datetime="2009-11-04" class="published updated">November 4th, 2009</time>
</div>
</footer>

If you view the source code on our home page, you’ll see that we’ve used the address element — nested within the footer of the articles — several times throughout the page. This is useful should the information be aggregated.

The wrong way

The most common misconception about the address element is that it should be used to mark up any old address. Take a look at the following example:

<!-- This is bad! -->
<address>
Dr. Jack Osborne
HTML5 Hospital,
Doctorville,
Great Britain
Tel: +44 (0)XXXX XXXXXX
</address>

Wondering what’s wrong with this code? Very simply, the address element was not created for postal addresses. To reinforce this, the latest spec stipulates that the address element must not be used to represent arbitrary addresses (e.g., postal addresses), unless those addresses are in fact the relevant contact information for a document or section of a document.

Marking up arbitrary addresses

So what should we do with addresses that aren’t directly related to the document? One solution is to use the p element in combination with the hCard microformat.

Let’s rewrite that last example using hCard:

<div class="vcard">
<p class="fn"><a class="url" href="#">Dr. Jack Osborne</a><p>
<p class="adr">
<span class="street-address">HTML5 Hospital</span>
<span class="region">Doctorville</span>
<span class="postal-code">Postal Code</span>
<span class="country-name">Great Britain</span>
</p>
<p class="tel">+44 (0)XXXX XXXXXX</p>
</div>

Unfortunately, an in-depth discussion of hCard is beyond the scope of this article. I’ve included it here to reinforce that you are not supposed to use the address element for arbitrary postal addresses, but rather for providing contact information for a whole document or section of a document. If you want to maximise the semantic value of that information, you can do so with the addition of a couple of simple classes.

If you don’t feel comfortable implementing microformats on your own, visit the hCard generator, which will do all of the heavy lifting for you.

Share and Save:

The Address Element originally appeared on HTML5 Doctor on November 3, 2009.

Update

When I wrote the previous version of this article a few months ago, I knew, as I’m sure many of you also knew, that this element in particular would be subject to change as the HTML 5 spec neared it’s completion. The problem was simple, the footer element just didn’t feel 'complete', it just didn’t offer the same flexibility as other elements. Now that’s changed.

In summary, the content model for the footer element has been changed to allow sectioning content like header or like nav. In fact it now works in very much the same way as the header element. However, it’s important to note that footer isn’t sectioning content and doesn’t introduce a new section.

If you’ve been working on a site and have incorporated a wonderful new footer with everything that it now allows please feel free to post a link in the comments to show other readers just what you can get away with.

Below is an updated copy of the original article.

Old Article

For some time now we’ve become accustomed to seeing <div id="footer"> at the bottom of web pages but with the introduction of HTML 5 it’s time to say goodbye. With the addition of the new <footer> element we now have more scope and flexibility.

According to the spec

The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.

Lets get started

Before we get stuck into dissecting the new element, let’s lay the foundations for the article and cover the basics. As we’ve already mentioned above, most people would have laid out the footer as follows

<div id="footer">
  <ul>
     <li>copyright</li>
     <li>sitemap</li>
     <li>contact</li>
     <li>to top</li>
  </ul>
<div>

However with the creation of HTML5 this is no longer the case. As you may already know, there is now no longer the need for the <div> element for many elements. In our case, when referring to the footer, the appropriate markup would be <footer>

<footer>
  <ul>
     <li>copyright</li>
     <li>sitemap</li>
     <li>contact</li>
     <li>to top</li>
  </ul>
</footer>

As I mentioned in the first paragraph, originally the <footer> element was only utilised once within our pages but with the introduction of the new element, this no longer needs to be the case. The <footer> element can now be used multiple times and to display all the extra information.

Using the footer element

An important point to note is that you are not restricted to use one <footer> element per site, you can use multiple footers, each of which will then become the <footer> for that section of the document. You could therefore have a <footer> for a <section> or an <article>.

Section

<section>
   Section content appears here.
   <footer>
   Footer information for section.
   </footer>
</section>

Article

<article>
   Article content appears here.
   <footer>
   Footer information for article.
   </footer>
</article>

To see an example of the <footer> within an article/section look no further than this very page. Scroll down beyond the article and you will notice the light grey text section, which falls directly after the “further reading”. This grey text section which gives information about trackbacks, responses, tags and categories is infact using the footer element.

Footer

We’ve already outlined what the new footer can look like above.

Other Thoughts

I was initially thrown off-course by the presentational name of the element; my use here isn’t at the bottom of the page, or even at the bottom of the article, but it certainly seems to fit the bill – it’s information about its section, containing author name, links to related documents (comments) and the like. There’s no reason that you can’t have more than one footer on page; the spec’s description says “the footer element represents a footer for the section it applies to” and a page may have any number of sections. The spec also says “Footers don’t necessarily have to appear at the end of a section, though they usually do.”

Bruce Lawson – http://www.brucelawson.co.uk/2009/marking-up-a-blog-with-html-5-part-2/

Conclusion

The footer element offers the chance to define web pages giving them the correct semantic mark-up that they deserve but it’s vital to use these new found tags as they were intended for. Let’s not get carried away and misuse this tag like we have done with tables and divs.

Futher reading

• http://www.whatwg.org/specs/web-apps/current-work/#the-footer-element

Share and Save:

The Footer Element Update originally appeared on HTML5 Doctor on September 29, 2009.

Since the launch of the site we’ve be welcoming questions regarding the HTML 5 spec through the contact form. It doesn’t matter if you think your question is too <H1>big</H1> or <small>small</small> we’re here to help.

Last month we decided to pull together a post that covered some of the emails that were sent in through the contact page. Since the publication of the last post we have received a lot more questions regarding the HTML 5 spec and have decided that some of these warranted another post.

Content Type

Christian asked:

In checking out various implementations of html5 around the web with a quick “view source”, I find everyone seems to specify content type in the headers like so; <meta http-equiv=”content-type” content=”text/html;charset=utf-8″> even though it’s already a part of the HTTP header.

Does it really need to be in both locations, or can we all cut out that redundancy as long as our servers are specifying the content type appropriately in the HTTP header?

If you take a look at Dr.Bruce’s weblog http://www.brucelawson.co.uk/ you will see that most of the information can be cut out and simplified. As more and more sites make the jump to HTML 5 you will be able to see what elements can and cannot be left out. If you’re interested in checking out more sites then please feel free to visit our sister site HTML 5 Gallery where you will be able to view the source of plenty of sites that are already sporting HTML 5 elements in their markup.

If you’re looking to take your reading even further then Dr. Remy has recently published an article entitled HTML5 boilerplates which should give you more information on the above.

HTML 5 & SEO

Julio asked:

I’m thinking of using HTML 5 in my projects as soon as possible, but I need to be sure that everything will work just as fine as HTML 4. My question is: Google (and other search engines) is already indexing HTML 5 sites? In terms of SEO, will I have any drawbacks?

In answer to your question, yes Google is indexing HTML 5 sites. Between us we run several sites built with HTML 5 markup and none of the Doctors have had any issues with our sites being indexed or competitive on key phrases.

In fact if you look at the source code of google.com you’ll see that their doctype is declared as <! doctype html> meaning it’s using HTML 5! Another site that is part of the Google group, Youtube, has also recently created a mock-up of their layout that can be found at http://www.youtube.com/html5 and this definitely shows that they are thinking about it. One last fact to help settle your nerves, if we’ve not managed to do it already, is that Ian Hickson who is writing the bulk of the HTML 5 spec works for Google so we don’t think you’ll have any problems.

HTML 5 Templates

Klaus asked:

Where can if find HTML 5 Templates?

When this email came in, we weren’t too sure by what Klaus meant so we’re tackling his question with two responses.

For static HTML pages you’d be hard pushed to find a better resource than Remy’s boilerplate explained here: http://html5doctor.com/html-5-boilerplates/

However, if you are looking for some HTML 5 Wordpress themes then have a look at the following:

• http://www.brucelawson.co.uk/2009/redesigning-with-html-5-wai-aria/
• http://diggingintowordpress.com/2009/07/free-html-5-wordpress-theme/
• http://www.thatstandardsguy.co.uk/blog/2009/04/03/brave-new-world-wordpress-theme/

WebSocket Support

Dave asked:

There’s a lot of features, and I can’t find anywhere that lists current support in major browser versions (and/or with Google Gears). The particular one I’m looking for is WebSocket support

This is a good resource for checking the state of browser support for a particular feature: http://a.deveria.com/caniuse/ Regarding web workers specifically, we’ve come across a library that implements Web Sockets and falls away when it’s available natively.

None of the doctors have used these personally but feel that they will be useful in answer to your question:

• http://orbited.org/
• http://molly.com/html5/html5-0709.html
• http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML_5)
• http://wiki.whatwg.org/wiki/Implementations_in_Web_browsers

Reusing Elements Within Same Page

Daniel asked:

Dear Doctor,
Just a quick confirmation please. Am I right in thinking that nav, like header and footer, can be used more than once in a single page? For example, surrounding a menu at the top of the page and surrounding next/previous buttons at the bottom. Come to think of it, is it fair to say that all tags except html, head and body can be used more than once?
Thanks in advance, doctor.
I’ll be back soon about my dodgy knee.

Yes, for more information please reference this article – http://html5doctor.com/designing-a-blog-with-html5/ and this diagram of a single blog entry (of course, there can be many blog entries on a page) http://html5doctor.com/wp-content/uploads/2009/06/html5-article-outline.gif probably.

Other articles that we have already covered on the site – http://html5doctor.com/the-header-element/, http://html5doctor.com/the-footer-element/ and a great article on the http://html5doctor.com/nav-element/.

Learning HTML/XHTML Before Reading About HTML 5

Manuel asked:

Hi, I’m new to this field and I would like to learn HTML.

If I understand correctly, most future web sites will be written in HTML5 (served using the text/html MIME type) and just a few sites will use XHTML5 (served using the application/xhtml+xml MIME type). As a consequence, I will focus on HTML5.

HTML5 can use both the HTML syntax and the stricter XHTML syntax, but since I’m starting from scratch I suppose I could safely ignore the XHTML syntax and focus on the HTML syntax (HTML 4.1/5). Why bother about XHTML syntax in 2009? Unfortunately all modern introductory book/online resources about HTML are focused on the XHTML syntax. Where I could learn the pure HTML syntax without any reference to the useless and distracting (for my purposes) XHTML syntax?

Your best bet would be to get into the good coding practices of XHTML (lowercase tag, always closing tags, etc.) while writing HTML, there are a number of resources on the Internet for learning HTML 4.01 which you shouldn’t have any problems finding. A particular favorite of mine when I was starting out was HTMLDog.

We understand the issue of a number of the resources use the XHTML sytax but as I said above this will get you into good coding habits when writing HTML (particularly as HTML is less strict).

thank you for your quick reply. You won me: I will learn XHTML (from HTMLDog). Just a last question: when in the next future I will make the transition to HTML5 (served using the text/html MIME type) I hope the XHTML syntax validates anyway, so that I will have just to change the doctype of my pages to <!DOCTYPE html>. Right? (My fear is that the XHTML syntax will require a XHTML5 doctype).

This is correct though you won’t get the extra semantics added by HTML 5. For that I suggest you read the articles that appear on the site. If you want to use semantic class naming in your current XHTML I suggest you see the related links after ‘Automated Conversion’ in this post. – http://html5doctor.com/your-questions-answered-1/

There we have it folks…

Another quick round up of some of the more difficult questions we’ve had to respond to over the last few weeks. We hope that you’ll find this article helpful and remember that if you have a question that hasn’t been covered in an article so far feel free to get in touch, you never know, your question might just appear in one of these posts.

Share and Save:

Your questions answered #2 originally appeared on HTML5 Doctor on August 20, 2009.

For some time now we’ve become accustomed to seeing <div id="footer"> at the bottom of web pages but with the introduction of HTML 5 it’s time to say goodbye. With the addition of the new <footer> element we now have more scope and flexibility.

According to the spec

The footer element represents the footer for the section it applies to. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.

Lets get started

Before we get stuck into dissecting the new element, let’s lay the foundations for the article and cover the basics. As we’ve already mentioned above, most people would have laid out the footer as follows

<div id="footer">
  <ul>
     <li>copyright</li>
     <li>sitemap</li>
     <li>contact</li>
     <li>to top</li>
  </ul>
<div>

However with the creation of HTML 5 this is no longer the case. As you may already know, there is now no longer the need for the <div> element for many elements. In our case, when referring to the footer, the appropriate markup would be <footer>

<footer>
  <ul>
     <li>copyright</li>
     <li>sitemap</li>
     <li>contact</li>
     <li>to top</li>
  </ul>
</footer>

As I mentioned in the first paragraph, originally the <footer> element was only utilised once within our pages but with the introduction of the new element, this no longer needs to be the case. The <footer> element can now be used multiple times and to display all the extra information.

Using the footer element

An important point to note is that you are not restricted to use one <footer> element per site, you can use multiple footers, each of which will then become the <footer> for that section of the document. You could therefore have

Section

<section>
   Section content appears here.
   <footer>
   Footer information for section.
   </footer>
</section>

Article

<article>
   Article content appears here.
   <footer>
   Footer information for article.
   </footer>
</article>

To see an example of the <footer> within an article/section look no further than this very page. Scroll down beyond the article and you will notice the light grey text section, which falls directly after the “further reading”. This grey text section which gives information about trackbacks, responses, tags and categories is infact using the footer element.

Footer

We’ve already outlined what the new footer can look like above.

Other Thoughts

I was initially thrown off-course by the presentational name of the element; my use here isn’t at the bottom of the page, or even at the bottom of the article, but it certainly seems to fit the bill – it’s information about its section, containing author name, links to related documents (comments) and the like. There’s no reason that you can’t have more than one footer on page; the spec’s description says “the footer element represents a footer for the section it applies to” and a page may have any number of sections. The spec also says “Footers don’t necessarily have to appear at the end of a section, though they usually do.”

Bruce Lawson – http://www.brucelawson.co.uk/2009/marking-up-a-blog-with-html-5-part-2/

Conclusion

The footer element offers the chance to define web pages giving them the correct semantic mark-up that they deserve but it’s vital to use these new found tags as they were intended for. Let’s not get carried away and misuse this tag like we have done with tables and divs.

Futher reading

• http://www.w3.org/TR/html5/semantics.html#the-footer-element

Share and Save:

The footer element originally appeared on HTML5 Doctor on June 29, 2009.