<div id="example-one" contenteditable="true">
<style scoped>
  #example-one { margin-bottom: 10px; }
  [contenteditable="true"] { padding: 10px; outline: 2px dashed #CCC; }
  [contenteditable="true"]:hover { outline: 2px dashed #0090D2; }
</style>
<p>Everything contained within this div is editable in browsers that support <code>HTML5</code>. Go on, give it a try: click it and start typing.</p>
</div>
    

The contenteditable attribute originally appeared on HTML5 Doctor on January 10, 2012.

Let’s take a quick look at the spec:

The scoped attribute is a boolean attribute. If set, it indicates that the styles are intended just for the subtree rooted at the style element’s parent element, as opposed to the whole Document.

How does it work?

In this section, I’ll show you how this new attribute will work when it gets rolled out to browsers.

Our starting point

We’ll be using the following code sample as a starting point:

<article>
  <h1>Style Scoped</h1>
  <p>The scoped attribute for the style element will eventually allow for you to include style elements mid-document. To do this, you must mark up your style element with the scoped attribute.</p>
  <section>
    <h2>How does it work?</h2>
    <p>Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.</p>
  </section>
</article>

This is a basic example, with two headings and two paragraphs set within the article element.

Adding the scoped attribute

In the next example, we’ll change the foreground color of the second paragraph to red (from whatever was defined in the master CSS file):

<article>
  <h1>Style Scoped</h1>
  <p>The scoped attribute for the style element will eventually allow for you to include style elements mid-document. To do this, you must mark up your style element with the scoped attribute.</p>
  <section>
    <style scoped>
      p { color: red; }
    </style>
    <h2>How does it work?</h2>
    <p>Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.</p>
  </section>
</article>

This screenshot shows how things might render in the browser:

The scoped attribute originally appeared on HTML5 Doctor on September 13, 2011.

We hope you will agree that this redesign is a long time overdue, as this summer will see the Doctor turn two!

When we decided to create the site our mission statement was simple; create excellent content. We like to think we have achieved this by publishing high quality articles and quizzes. However, because of this the aesthetics of the site have remained the same and we felt it was time we gave the surgery a lick of paint. Now that we’ve built up a good base on content, we felt that the time was right to give the site some much needed TLC.

Redesigning a website is hard, redesigning a website which is used by tens of thousands of people is even harder and is probably the main reason why our redesign process dates back to 18th August and is only just seeing the light of day.

More than just a redesign

The project kicked off when our good friend, Oliver Ker, was approached to inject new life into our brand. What we were looking for was an instantly recognisable symbol, something which people would be able to relate to HTML5. We think Oli has done a stellar job with our new branding and it provides us with an instantly recognisable identity to build upon. If you are interested in finding out more about the creative process then head over to Olivers blog and see what he has to say.

Once we had a brand to work from we decided to start mocking up possible solutions for a direction we could take the site in. We were all in agreement as to which areas of the site needed addressing; it had to be simpler in all aspects, easier to read and utilise more of the newer technologies available.

Undoubtedly, you will have heard or experienced for yourself the issues faced when trying to design your own site and this site was certainly no different.

We considered multiple different design solutions – probably one for each Doctor – and it was only at our fifth attempt that we finally started to head in the direction which is now presented before you. The multiple design directions we went down is something I will cover on my own blog as it is out with the scope of this article.

Layout

Barring a select few pages such as the element index (previously the glossary), HTML5 Doctor is represented with a three column layout, the first column is slim and narrow which contains meta information for items related to the page/post.

The second column is the main content holder which is where all the page, post(s) and comment(s) content appear.

The final column, which for want of a better word is essentially our sidebar that contains an array of information such as element index links, related posts, categories and authors, a twitter display which pulls out hashtags and advertisment blocks.

At the top of the site we’ve completed reworked the header which should hopefully make navigating the site much easier. We’ve provided users with two different navigation bars; the top menu provides an easy way to access all our secondary content and we’ve also introduced our ‘Doctor network’ dropdown to provide access to our sister site HTML5 Gallery. Our main menu, located on the light blue bar, has been minimised to extremes, offering links to exisiting articles, the element index and our contact page. We’ve moved our search element higher up the page and plan to introduce breadcrumbs.

Page structure

Time to break down individual pages:

Homepage

With this being the most visited page on the site we wanted to try and do something a little special with it and for a long time we were devoid of any ideas until Doctor. Oli (@boblet) came up with an idea which would help offer up all the valuable information that is scattered throughout the site and pull it all together.

First up we display our most recent article, which sits front and centre to provide it with the attention it deserves. The following item is the quick reference guide which links through to each entry in the element index. There are two very special things about our quick reference guide which we are very proud about:

1. The hover states within this section have been created in canvas, by canvas supremo Rob Hawkes. Although this might not be the correct choice – many would argue SVG – we felt that this provided a fair trade-off and allowed us to use this new technology.
2. Second is that we can use this guide to promote a special subject – special subjects will have a bright orange background – which stands out from the regular hover states.

After the reference guide we display a few more posts.

HTML5 Doctor Article/Single page

This layout follows on from that of the homepage. Here we have a meta column on the left which offers up a series of quick links for categories, tags and will when applicable show links to translated versions of the article. The main column is obviously where the article and comments will appear and the third column is where all the extra information appears.

Element Index

We’ve restyled the index so it is in fitting with the new design and we’ve added in all the content and code examples that were missing from the previous iteration. We’re sorry for being lazy and not finishing it when we first launched.

A word on technologies

At the start of this article we touched on the fact that we wanted to introduce some of the newer technologies (or perhaps more wide spread) available to the site. Some of the things we have included are:

• @font-face: We’ve used Quicksand on our heading levels as this ties into our branding. Quicksand is a free font which can be downloaded here.
• CSS3: last-child, first-child, (n)th-of-type, border-radius, canvas, gradients, box-shadow.
• There are a few more easter eggs hidden under our lab coats but we’ll let you find them for yourself

Our prescription

As we’ve said above, everything is still a work in progress, we will continue to evolve the site moving forward. Essentially, we felt that now was as good a time as any to push this out into the wild and let our readers form an opinion and offer up there thoughts on the design. If we didn’t do it now, we’d be forever arguing over the semantics of the design, the leading here and the letter spacing there. So feel free to leave a comment and tell us what you think, whether it covers design/semantics/typography. We look forward to hearing from you. Enjoy.

Injecting new life into the Doctor originally appeared on HTML5 Doctor on May 26, 2011.

To offer a quick recap, hgroup was removed from the W3C specification only (not the WHATWG spec) by Hixie at the request of Steve Faulkner. The co-chairs requested the issue be reverted following multiple requests from the likes of Tab and Tantek. The current status at the time of writing is that hgroup is in the spec.

It seems that the future of hgroup will be decided during the HTML5 spec last call review which is expected to start on or around May 22nd 2011.

One of the main reasons for this element being removed was because some people felt that it was only in the spec was to keep the outline algorithm happy and that it didn’t really offer much else in the way of semantics. It has also been suggested that people were still struggling to understand how to implement it correctly. If, however, you need your memory jogging then we suggest reading our post on hgroup from last year.

Far be it from us to get involved in the political wrangling (and knob waving) of the W3C, therefore when news of this broke we doctors fired a few emails between each other discussing what was going on and what we thought should be the next logical step. The outcome from these emails showed that there was no clear majority. Some of the doctors, myself included, thought that the element was a handy addition to the spec and should be something that we fought to keep. Others, like Bruce, have made no qualms about their dislike for this particular element.

Regardless, we decided to see if we could solve this issue by offering up alternative solutions. Below are a few of the suggestions (and issues) that came out of the conversation. We understand that some of these suggestions come with their own issues and the consequences maybe haven’t been fully thought through, but the aim of this is to start a conversion, not provide a final answer.

<article>
  <header>
    <hgroup>
      <h1>Title goes here</h1>
      <h2>Subtitle of article</h2>
    </hgroup>
    <p><time datetime="2010-03-20">20th March, 2010</time></p>
  </header>                
  <p>Lorem Ipsum dolor set amet...</p>
</article>

Subtitle within header

<article>
  <header>
    <h1>Title</h1>
    <p>subtitle</p>
  </header>
  <p>Lorem Ipsum dolor set amet...</p>
</article>

The method suggested above is probably the closest example to what we currently have with regards to hgroup. Within this code example we have an heading level and p tag within the header element.

Although this might seem fairly straight forward, it does become more complicated if we have further elements within the header; additional p tags, spans etc.

Highest ranking heading takes precedence

<article>
  <header>
    <h4>Intro subtitle</h1>
    <h1>Title goes here</h1>
    <h3>by John Smith</h3>
    <p><time datetime="2010-03-20">20th March, 2010</time></p>
    <nav>
      <h2>Chapters</h2>
      <ul>...</ul>
    </nav>
  </header>                
  <p>Lorem Ipsum dolor set amet...</p>
</article>

Taking the previous example a bit further, here we have multiple headings within header and the machine could recognise that the h1 is the highest ranking and should be used in the outline. Other headings are excluded, with the exception of the h2 within nav as it is a sectioning content element and therefore still affects outline.

This allows the developer to have multiple subtitles of varying importance without affecting the outline. The drawback of this is the use of headings isn’t very intuitive when lower ranking headings can appear anywhere within header. Thankfully we still have ideas for other alternatives.

Span subtitle within header

<article>
  <header>
    <h1>Title <span>Subtitle</span></h1>
  </header>
  <p>Lorem Ipsum dolor set amet...</p>
</article>

This next technique is probably similar to something that you might have used before when coding up a page in HTML4, providing something of a natural progression, paving the cowpaths if you will. As the span is within the heading element it makes it clear that it is associated with the heading.

Some of the doctors are not convinced this is the correct way to progress and therefore looked for another alternative.

Introducing the subtitle

<article>
  <header>
    <h1>Title <span subtitle>Subtitle</span></h1>
  </header>
  <p>Lorem Ipsum dolor set amet...</p>
</article>

This example is almost identical to the example provided above. The only difference here is that we’ve added a subtitle attribute to help assistive software make the connection between heading and subtitle. Again, some Doctors are not completely comfortable with nesting a subtitle within a heading element.

It was also suggested combining this example and the first to come up with a better outcome. Whereby a developer would include a heading and p tag, marked up with the subtitle attribute, within the header element.

For attribute within header

<article>
  <header>
    <h1 id="title">Title</h1>
    <p for="title">Subtitle</p>
  </header>
  <p>Lorem Ipsum dolor set amet...</p>
</article>

Now for something totally different. The above example borrows an idea from forms using the for attribute. in HTML5, a number of elements which were previously required to be within a form element can now be located anywhere on the page and associated with a form using a form attribute pointing at the id of its form owner. This example extends borrows the idea an applying it to use with another attribute and element.

In our example the p tag is owned by the heading element. The interesting thing with this method, along with the forms, is that the subtitle wouldn’t necessarily have to be nested within the header, as assistive technology would still be able to associated which heading it belonged too.

What’s next and your suggestions

Issue 164 on the W3C tracker offers some further suggestions to how hgroup could be removed, modified or otherwise changed. Some of those are similar or the same as those we’ve mentioned above but now you’ve seen our suggestions and perhaps perused those in issue 164, so why not let us know your suggestions below in the comments.

This is a fairly big issue and one that a lot of people are still obviously undecided about, so here is your chance to seize an opportunity because, you never know, your suggestion could become standard practice.

The hgroup hokey cokey originally appeared on HTML5 Doctor on May 6, 2011.

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

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

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.

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

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.

W3C HTML5 specification

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>,
<a href="http://html5doctor.com/author/olib">Oli Studholme</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<br>
HTML5 Hospital,<br>
Doctorville,<br>
Great Britain<br>
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><br>
<span class="region">Doctorville</span><br>
<span class="postal-code">Postal Code</span><br>
<span class="country-name">Great Britain</span>
</p>
<p class="tel">+44 (0)XXXX XXXXXX</p>
</div>

I’ve introduced hCard 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, read our articles on extending HTML5 with microformats or HTML5’s new microdata attributes.

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.

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

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

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

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.

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

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

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