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.

“Sorry, can you say that again?”, I hear you ask. Certainly: you can still use <div>! Despite HTML5 bringing us new elements like <article>, <section>, and <aside>, the <div> element still has its place. Let the HTML5 Doctor tell you why.

Status: Unchanged

In HTML 4, the <div> element was defined to be a generic element for structuring a page. Although you can allude to the nature of its content by assigning id and class attributes with meaningful names, a <div> has almost no semantic meaning. The HTML5 definitionis basically the same as in HTML 4:

The div element has no special meaning at all. It represents its children. It can be used with the class, lang, and title attributes to mark up semantics common to a group of consecutive elements.

<div> is literally a container for flow content*, a collection of (hopefully) more semantically marked-up content that may need to be grouped together. It lies at the opposite end of the semantic spectrum from the new HTML5 structural elements.

* For those who haven’t encountered this term before, flow content elements are the same as HTML 4’s block-level content elements.

<div> vs semantic elements

The new semantic elements (<article>, <section>, and friends) justifiably capture a lot of <div>’s territory, but <div> still has a place in the HTML5 world. You should use <div> when there is no other more semantically appropriate element that suits your purpose. Its most common use will likely be for stylistic purposes — i.e., wrapping some semantically marked-up content in a CSS-styled container.

Ask yourself questions about your content: Is it part of the site’s navigation? Is the content secondary to its surrounding content? If this content were printed on a page with nothing else, would it make sense? You will need to evaluate your content carefully, thinking about what it is and pairing it with an appropriate element. I recommend taking a look at The Amazing HTML5 Doctor Easily Confused HTML5 Element Flowchart of Enlightenment to help you choose the right element for your flow content.

Example Uses

Below are a few examples of how you can still use <div> appropriately in your HTML5 sites.

Site Wrapper

While you can use the <body> element as a “natural” wrapper for site content, many people like to use <div> as top-level container for styling the entire site. This is an appropriate use of <div>, as a site wrapper has no meaning or purpose other than to aid styling.

<body>
  <div id="wrapper">
    <header>
      <h1>My Happy Blog</h1>
      <nav>
        <!-- ... -->
      </nav>
    </header>

    <!-- ... rest of site content ... -->
  </div>
</body>

Intro paragraph

If you want to style a particular block of content, like the intro to an article, <div> is a perfectly suitable element:

<article>
  <h1>Big announcement</h1>
  <div class="intro">
    <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.</p>
    <p>Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.</p>
  </div>
  <p>Sed massa metus, molestie nec facilisis non, lobortis ac orci. Suspendisse porttitor laoreet mi, at laoreet dolor rhoncus non. Sed ut massa quis mi placerat iaculis non sit amet odio. Cras tempus urna vitae felis rutrum porta.</p>
  <p>Maecenas auctor lacus eget mauris tincidunt consectetur. Donec molestie malesuada ligula, sed feugiat massa consequat sit amet. Pellentesque orci metus, ultricies sit amet adipiscing eget, gravida fringilla dui. Vestibulum accumsan dui diam, eget venenatis urna. Sed eu lobortis justo. Aliquam erat volutpat. Aliquam erat volutpat.</p>
</article>

The first two paragraphs aren’t really that different from the rest of the article, but by wrapping them in a <div>, they can be styled to capture the reader’s attention and draw them into the article. Of course, if you only want to style the first paragraph, you could use a CSS selector like h1 + p {} or article p:first-child {}. But if you want to style an article’s first paragraph only sometimes, or you need the style to work in older versions of Internet Explorer, or (as in this case) you want style more than one paragraph, a wrapper <div> is the way to go.

Other uses for <div>

As previously stated, use of <div> will decline in favour of the new semantic elements. If you’re using lots of <div>s and only a few of the semantic elements in your HTML5 sites, then you’re really not taking advantage of what HTML5 has to offer.

That said, you may need to rely on <div> as you transition into the world of HTML5. For example, if many of your site’s visitors use Internet Explorer with JavaScript disabled, then you won’t be able to style the new elements for these users. A piece of advice we gave back in our article on how to use HTML5 in your client work right now was to use <div> with classes named after the new semantic elements, getting you to think about how you would use the new semantic elements without actually using them.

<div class="article">
  <div class="header">
    <h1>My blog post</h1>
    <p>An example using divs with classes instead of the new elements.</p>
  </div>
  <!-- ... content ... -->
</div>

<article>
  <header>
    <h1>My blog post</h1>
    <p>The same article but switched to the new elements.</p>
  </header>
  <!-- ... content ... -->
</article>

This makes it simple to switch to the new elements when it becomes practical (think “search and replace”).

Recap

You will certainly use <div> less often in HTML5 than you did in HTML 4, but it’s still a valuable element to have in your toolkit. Sure, it’ll be picked last for the team because everyone else is better, but it’ll be the best damn generic container element there is!*

Look at the more semantically valuable elements and consider whether your content would benefit from what they offer. Need help deciding? Take a look at some of these articles right here on HTML5 Doctor:

• header
• footer
• aside
• article
• section
• figure
• nav

For more, check our article archive. And if all else fails, use a <div>!

* As it should be, it’s the only one apart from <span>. That said, if your content is just text, perhaps the oft-overlooked <p> would be more appropriate.

Share and Save:

You can still use div originally appeared on HTML5 Doctor on July 13, 2010.

The clinic is getting busy with more HTML5 ailments. This week, we’ll cover using sections within a footer, <canvas> vs. Flash security, why HTML5 elements are treated as inline, using offline with storage, and marking up block quotes.

<!doctype html>
<meta charset=utf-8>
<title>blockquote test</title>
<blockquote>Tiger tiger burning bright</blockquote>

Your Questions Answered #10 originally appeared on HTML5 Doctor on July 9, 2010.

It’s our birthday and we’ll cry if we want to, or so the song goes. Today marks HTML5 Doctors first birthday so we thought we’d let you in on the celebrations. This brief post takes us through a little recap of what we’ve done, looks at what’s to come and we’ve even got a little birthday treat for you all – the HTML5 equivalent of bringing doughnuts to work.

What we’ve done

The site was launched publicly a year ago today and what a year it’s been. We could never have expected the level of interest we’ve had nor that the site would be so well received. We’d like to thank you all for reading, commenting and linking to our articles. We intended the site to have a community feel and feel we’re continuing to work towards that.

Having met through twitter and then in person at FOWD 2009 the idea was formed over a few beers. The name derives from a certain Mr Zeldman’s “Ask Dr Web” (“A complete guide to web design”). You can find a little more on our history over on the about page.

We started with five doctors (Jack, Tom, Mike, Bruce & Rich), which became six just before launch when Remy came on board. We’ve since grown to seven with the indomitable Mr Studholme joining our ranks several months ago. Extra credit should also go to Brandan Lennox who knuckles away in the background studiously editing our copy. Between us we’ve managed to crank out more than a post a week, which we hope will increase in the coming year.

We’ve also had several guest authors who have covered some great topics such as audio in the browser, why designers should care about HTML5 and data attributes so thanks to Mark, Cennydd & Chris.

Last November we launched the glossary which offers an introductory view to HTML5 elements with code examples and links to our more in depth articles. It’s been a well used resource and we’re adding to it all the time, slowly building it up to be a complete resource.

In terms of events at least one of our team has spoken at a number of events in the past year, not least Bruce (with Martin Kliehm) being voted the 4th best talk at SXSWi. Also, earlier this month we ran a HTML5 clinic at Web Directions @Media in London. I think we managed to help quite a few people out down there. Remember to get in touch if you’re looking for someone to talk HTML5 at your event or you feel you need an emergency clinic setting up.

Future Plans

That’s enough looking back, now let’s start looking forward. We’ve got some cracking posts and super developments in the works for the coming months. I can’t say much more than that right now but I can tell you we’ll have articles on web forms, canvas, microdata and taking your applications offline in the not too distant future.

What we’d really love to do is to start writing articles that you, our readers want. So here’s your chance, if you’ve got a topic you’d like us to cover or an idea for the site then please leave a comment below. We’ll take a look through them and get writing.

A small gift

Everyone likes to receive a present on their birthday right? Well for our birthday we decided to give you a present, in the form of a handy flowchart to help you choose the most semantically appropriate HTML5 element. Those lucky folk who attended @media already received have a hard copy but here’s the electronic version you asked for.

Inspired by an original version sent in by Piotr (one of our readers) and developed by Oli the chart helps guide you through those tricky differences between header, footer, aside, section, article, figure and yes, div. It’s available in either pdf or png format.

We hope you find it useful and we’d love to hear any feedback you might have.

All that’s left for us to say is thanks for a great first year and here’s to the next one!

Happy 1st Birthday us originally appeared on HTML5 Doctor on June 29, 2010.

The <dl> element existed in HTML 4, but it’s been repurposed in HTML5. Let the Doctor explain what’s changed and how it can be used.

It’s all in the description

In HTML 4, <dl> was considered a “definition list”, containing groups of terms and their definitions. The terms and definitions were a many-to-many relationship: one or more terms to one or more definitions. The element was often misunderstood and therefore misused or not used at all in favour of more widely used and (perhaps) less semantic markup.

To address these issues, <dl>’s definition has been refined in HTML5 as a description list. From the spec:

The dl element represents an association list consisting of zero or more name-value groups (a description list). Each group must consist of one or more names (dt elements) followed by one or more values (dd elements). Within a single dl element, there should not be more than one dt element for each name.

It maintains the many-to-many relationship between names and values. These groupings use <dt> to represent the term or name and <dd> for the description. Also note the last line of the quote, stating that a name should not be used more than once within a single <dl>.

Example Uses

I’ve put together a couple of appropriate uses of <dl> to get your creative juices flowing.

Glossary

<dl> can be used to mark-up a glossary of terms, although you must remember to use <dfn> to indicate that the word is defined here:

<article>
  <h1>The article element</h1>
  <p>An independent piece of content, one suitable for putting in an
    article element, is content that makes sense on it’s own. This yardstick
    is up to your interpretation, but an easy smell test is would this make sense
    in an RSS feed? Of course weblog articles and static pages would make sense
    in a feed reader, and some sites have weblog comment feeds..</p>
  ...
  <aside>
    <h2>Glossary</h2>
    <dl>
      <dt><dfn>RSS</dfn></dt>
      <dd>An XML format for aggregating information from websites whose
        content is frequently updated.</dd>
      <dt><dfn>Weblog</dfn></dt>
      <dd>Contraction of the term "web log", a weblog is a
        website that is periodically updated, like a journal</dd>
    </dl>
  </aside>
</aticle>

The example content is from our recent post on the article element. In the example, I plucked out the terms “RSS” and “weblog” and defined them in a handy glossary. Since this information is supplementary to the article, the glossary has been placed in an <aside>.

Metadata

<dl> is also appropriate for marking up content metadata, such as information about our article on how to use HTML5 in your client work right now.

<dl>
  <dt>Authors:</dt>
  <dd>Remy Sharp</dd>
  <dd>Rich Clark</dd>
  <dt>Editor:</dt>
  <dd>Brandan Lennox</dd>
  <dt>Category:</dt>
  <dd>Comment</dd>
</dl>

Since Remy and Richard contributed to that article, they are both listed as authors, showing the pairing of multiple values (<dd>) to one key (<dt>).

Multiple keys (<dt>) to a single value

As mentioned above, a <dl> may map many keys (<dt>) to many values (<dd>). This means that one term might have multiple descriptions, or there may be multiple terms that mean the same thing. Related <dt>s should follow each other immediately before their descriptive <dd>.

<dl>
  <dt lang="en-GB"><dfn>colour</dfn></dt>
  <dt lang="en-US"><dfn>color</dfn></dt>
  <dd>The visual result of light in their emission, transmission and/or reflection. This perception is determined by the hue, brightness and saturation of the light at a specific point. </dd>
</dl>

Here I have indicated that there are two different spellings of “colour” and grouped these terms to match them with the same description.

It is not appropriate, however, to use the same key multiple times within a single <dl>. You can’t define “car” as one thing at the start of a <dl> and then define it again at the end of that same <dl>. If you have multiple descriptions for a single term, you should list both <dd>s directly under the same <dt>.

<dl>
  <dt><dfn>Chips</dfn></dt>
  <dd>Strips of potato usually deep fried in fat. Commonly referred to as "french fries".</dd>
  <dd>A small fragment that has been broken off from a larger body (e.g. stone).</dd>
</dl>

What it should not be used for

Dialogue was a suggested use for <dl> in HTML 4, which was widely debated and often considered inappropriate. This application of the element is no longer recommended in HTML5, and the new definition of the element does indeed back this up. When marking up a conversation, you’re not describing the speaker, but rather stating what they said. With the demise of <dialog>, conversations have no specific markup element. Instead, the specification makes recommendations of how to mark up conversations.

Summary

The changes to <dl> are fairly minor, but the new definition should clear up confusion and enable developers to use it more appropriately. You can use this element to represent key-value pairs semantically and couple it with other elements like <details> and <aside> to give context to this information.

Where do you see yourself using <dl> in HTML5? Perhaps details about a downloadable file? Or are you going to give your more technical blog articles a glossary? Let us know in the comments!

Share and Save:

The dl element originally appeared on HTML5 Doctor on June 3, 2010.

Have you ever found yourself using element class names or rel attributes to store arbitrary snippets of metadata for the sole purpose of making your JavaScript simpler? If you have, then I have some exciting news for you! If you haven't and you're thinking, Wow, that's a great idea! I implore you to rid your mind of that thought immediately and continue reading.

Thanks to HTML5, we now have the ability to embed custom data attributes on all HTML elements. These new custom data attributes consist of two parts:

Attribute Name

The data attribute name must be at least one character long and must be prefixed with 'data-'. It should not contain any uppercase letters.

Attribute Value

The attribute value can be any string.

Using this syntax, we can add application data to our markup as shown below:

<ul id="vegetable-seeds">
  <li data-spacing="10cm" data-sowing-time="March to June">Carrots</li>
  <li data-spacing="30cm" data-sowing-time="February to March">Celery</li>
  <li data-spacing="3cm" data-sowing-time="March to September">Radishes</li>
</ul> 

We can now use this stored data in our site’s JavaScript to create a richer, more engaging user experience. Imagine that when a user clicks on a vegetable a new layer opens up in the browser displaying the additional seed spacing and sowing instructions. Thanks to the data- attributes we’ve added to our <li> elements, we can now display this information instantly without having to worry about making any Ajax calls and without having to make any server-side database queries.

Prefixing the custom attributes with data- ensures that they will be completely ignored by the user agent. As far as the browser and indeed the website’s end user are concerned, this data does not exist.

The spec says (emphasis ours):

Custom data attributes are intended to store custom data private to the page or application, for which there are no more appropriate attributes or elements.

These attributes are not intended for use by software that is independent of the site that uses the attributes.

Every HTML element may have any number of custom data attributes specified, with any value.

W3C Specification

How can I use data attributes?

As custom data attributes are valid HTML5, they can be used in any browser that supports HTML5 doctypes. Thankfully, this is pretty much all of them. In addition to aiding backwards compatibility, this also ensures that custom data attributes will remain a scalable, cross-platform solution well into the future.

Now that we have a broad understanding of what data attributes are, let's take a look at how they can be used:

• To store the initial height or opacity of an element which might be required in later JavaScript animation calculations
• To store parameters for a Flash movie that’s loaded via JavaScript
• To store custom web analytics tagging data as demonstrated by Jason Karns
• To store data about the health, ammo, or lives of an element in a JavaScript game
• To power accessible JavaScript <video> subtitles as demonstrated by Bruce Lawson

What shouldn’t I use data attributes for?

Although flexible, data attributes aren’t an appropriate solution for all problems.

• Data attributes should not be used if there is a existing attribute or element which is more appropriate for storing your data. For example, date/time data should probably be presented semantically in a time element instead rather than stored in custom data attributes.
• Custom data attributes are not intended to compete with microformats. It is clearly stated in the spec that the data is not intended to be publicly usable. External software should not interact with it. Marking up contact details or event details using custom data attributes would be wrong, unless of course it is only intended to be used by your own internal scripts.
• The presence/absence of a particular data attribute should not be used as a CSS hook for any styling. Doing so would suggest that the data you are storing is of immediate importance to the user and should be marked up in a more semantic and accessible manner.

Using data- attributes with JavaScript

Now that we understand what custom data- attributes are and when we can use them, we should probably take a look at how we can interact with them using JavaScript.

If we wanted to retrieve or update these attributes using existing, native JavaScript, then we can do so using the getAttribute and setAttribute methods as shown below:

<div id='strawberry-plant' data-fruit='12'></div>

<script>
// 'Getting' data-attributes using getAttribute
var plant = document.getElementById('strawberry-plant');
var fruitCount = plant.getAttribute('data-fruit'); // fruitCount = '12'

// 'Setting' data-attributes using setAttribute
plant.setAttribute('data-fruit','7'); // Pesky birds
</script>

This method will work in all modern browsers, but it is not how data- attributes are intended to be used. The second (new and improved) way to achieve the same thing is by accessing an element’s dataset property. This dataset property — part of the new HTML5 JavaScript APIs — will return a DOMStringMap object of all the selected element's data- attributes. When using this approach, rather than using the full attribute name, you can ditch the data- prefix and refer to the custom data directly using the name you have assigned to it. Data attribute names which contain hyphens will be stripped of their hyphens and converted to CamelCase.

<div id='sunflower' data-leaves='47' data-plant-height='2.4m'></div>

<script>
// 'Getting' data-attributes using dataset 
var plant = document.getElementById('sunflower');
var leaves = plant.dataset.leaves; // leaves = 47;

// 'Setting' data-attributes using dataset
var tallness = plant.dataset.plantHeight; // 'plant-height' -> 'plantHeight'
plant.dataset.plantHeight = '3.6m';  // Cracking fertiliser
</script>

If, at some point in your script, a specific data- attribute becomes redundant and is no longer needed, it is also possible to completely remove that attribute from the DOM element by setting it to a value of null.

plant.dataset.leaves = null; // Caterpillars attack!

Unfortunately, the new dataset property has not yet been implemented in any browser, so in the meantime it’s best to use getAttribute and setAttribute as demonstrated earlier.

While developing your application, you may find it useful to be able to select elements based on the presence of — or indeed the specific values of — their custom data- attributes. This can be achieved quickly and easily using querySelectorAll as shown below:

// Select all elements with a 'data-flowering' attribute
document.querySelectorAll('[data-flowering]');

// Select all elements with red leaves
document.querySelectorAll('[data-foliage-colour="red"]');

A word of warning

As data attributes become more widely used, the potential for clashes in naming conventions becomes much greater. If you use an unimaginative attribute name such as data-height, then it is likely you will eventually come across a library or plugin that uses the same attribute name. Multiple scripts getting and setting a common data- attribute will probably cause chaos. In order to avoid this, I encourage people to choose a standard string (perhaps the site/plugin name) to prefix all their data- attributes — e.g. data-html5doctor-height or data-my-plugin-height.

Summary

Custom data- attributes are a great way to simplify the storage of application data in your web pages. Although you can’t utilise the new JavaScript APIs just yet, you can enjoy great success using getAttribute and setAttribute safe in the knowledge that they will work in all major browsers.

Homework

If you’re super keen to have a play with the new dataset property but disappointed that it hasn’t been implemented, fear not!, for there is a light at the end of the tunnel. You might be interested in looking at Dr Remy’s experimental code, which partially enables the dataset functionality in some browsers by editing the Element.prototype.

The code supports the retrieval of data- attributes in the latest versions of Firefox, Safari, Opera, and Chrome, but sadly will not work in any version of IE (since IE does not expose the Element object). This code also partially supports the setting of data attributes, but it will only store the new attribute values within the JavaScript and will not update the DOM element as a full, native implementation of the dataset property would. Although this code is mainly a proof of concept, it may be useful for mobile application or intranet development in closed environments where cross-browser (IE) compatibility is not an issue.

HTML5 Custom Data Attributes (data-*) originally appeared on HTML5 Doctor on May 27, 2010.

We’ve discussed a lot of new elements here at HTML5Doctor, but the article element has somehow escaped the microscope… until now! article is one of the new sectioning elements. It is often confused with section and div but don’t worry we’ll explain the difference between them.

<article>
	<h1>Apple</h1>
	<p>The <b>apple</b> is the pomaceous fruit of the apple tree...</p>
	...
</article>

<article>
  <header>
    <h1>Apple</h1>
    <p>Published: <time pubdate="pubdate">2009-10-09</time></p>
  </header>
  <p>The <b>apple</b> is the pomaceous fruit of the apple tree...</p>
  ...
  <footer>
    <p><small>Creative Commons Attribution-ShareAlike License</small></p>
  </footer>
</article>

<article>
  <header>
    <h1>Apple</h1>
    <p>Published: <time pubdate datetime="2009-10-09">9th October, 2009</time></p>
  </header>
  <p>The <b>apple</b> is the pomaceous fruit of the apple tree...</p>
  ...
  
  <section>
    <h2>Comments</h2>
    <article>
      <header>
      <h3>Posted by: Apple Lover</h3>
      <p><time pubdate datetime="2009-10-10T19:10-08:00">~1 hour ago</time></p>
    </header>
    <p>I love apples, my favourite kind are Granny Smiths</p>
    </article>
    
    <article>
      <header>
        <h3>Posted by: Oranges are king</h3>
        <p><time pubdate datetime="2009-10-10T19:15-08:00">~1 hour ago</time></p>
      </header>
      <p>Urgh, apples!? you should write about ORANGES instead!!1!</p>
    </article>
  </section>
</article>

<article>
  <h1>Apple varieties</h1>
  <p>The apple is the pomaceous fruit of the apple tree...</p>

  <section>
    <h2>Red Delicious</h2>
    <p>These bright red apples are the most common found in many supermarkets...</p>
  </section>

  <section>
    <h2>Granny Smith</h2>
    <p>These juicy, green apples make a great filling for apple pies...</p>
  </section>
    
</article>

<section>
  <h1>Articles on: Fruit</h1>

  <article>
    <h2>Apple</h2>
    <p>The apple is the pomaceous fruit of the apple tree...</p>
  </article>

  <article>
    <h2>Orange</h2>
    <p>The orange is a hybrid of ancient cultivated origin, possibly between pomelo and tangerine...</p>
  </article>

  <article>
    <h2>Banana</h2>
    <p>Bananas come in a variety of sizes and colors when ripe, including yellow, purple, and red...</p>
  </article>
    
</section>

<article>
  <h1>My Fruit Spinner</h1>
  <object>
    <param name="allowFullScreen" value="true">
    <embed src="#" width="600" height="395"></embed>
  </object>
</article>

pubdate
pubdate="pubdate"

The article element originally appeared on HTML5 Doctor on May 18, 2010.

The Doctor is in with another round of patient questions about HTML5. This week, we’ll cover offline viewing on requests, the drag-and-drop API, using href on any element, the <figure> element, and headings.

Offline viewing on requests

Johan asked:

It is possible to let Firefox 3.5/3.6 save a page for offline viewing with the manifest file?
In that case Firefox asks for permission to save the site the same second you arrive – not very user-friendly.

Is it possible to send the save-it-locally request via Javascript on a click?

Basically I want a link/button which will fire the request – and not on document load.

While it isn’t possible to make Firefox 3.5/3.6 save a page for offline viewing with the manifest file, there is a way to do this. It all depends on how you write the “save-it-locally request” code. You have two options:

1. If you want to store an arbitrary document that is not explicitly listed in your manifest, you could run an Ajax request for that document and store its contents in localStorage. When you want to view that document, load it from localStorage and overlay it on the existing page.
2. Dynamically manage a manifest file for individual users, so that if a user requests a new file that isn’t in their manifest, register this on the server side and add it to the manifest — which is bespoke to this specific user — on the fly.

I’m not sure what you’re seeing with regards to the permissions error. When I test the manifest (offline **cache**), it doesn’t ask twice.

Note: you asked about Firefox 3.5 — the offline manifest doesn’t work properly at all in this version.

Thanks, Remy

Question about dragging

Marc asked:

Evening,

I’m trying to get my head around the drag and drop (DnD) possibilities of HTML5. I have a “simple” task: Read the content of a XML file, using JavaScript, and do some manipulations of he XML. Without the use of server side scripts.

I tried my way with Google, but apart from people complaining about the DnD specs, I wasn’t able to find much insightful informations.

Can you point me toward resources to understand the DnD possibilities of HTML5?

Thank you Doctor, a French canadian HTML5 fan

Absolutely! There’s actually an HTML5 Doctor article covering native drag-and-drop. It also includes links for further reading and related posts (such as accessibility experiments).

I hope that helps.

Cheers, Remy

About the href on any element

Luan asked:

I’ve heard a long ago that href would work in any tag, such as a <p href="..."> or a h1, even a div and others… but I don’t see anything about this in the last days. Do you know if this is going to work?

That was in XHTML2 (on which the W3C have now stopped work).

The HTML5 equivalent is to wrap an <a href="..."> around the other tags. It’s called block-level linking, and we’ve written an article about it.

Cheers, Bruce

W3C Validator for the <figure> element

Fjpoblam asked:

I have a (prospective) structure containing 8 figures: each an image with a caption. My goal is an image gallery, each image clickable toward an individual htm file containing a slide show. (In html4 I structured each “figure” as a div: figure seemed ideal for the task.)

Problem is, I tried to follow the *validator* hint with a dd for the image and a dt for the caption (each surrounded by an a). Upon doing so, the validator pops up an error. When I try a straight image with a legend, it is also rejected for want of a dd and an optional dt.

What gives? Do you have a hint? Or better, simply, point me doofus to the correct doc so’s you’ll “teach a man to fish”.

I’m not sure if the validator is up to date or not, but you shouldn’t be using <dd>/<dt> in <figure> anymore. Please use <figcaption>.

See our article on the <figure> and <figcaption> elements for more.

Also see our glossary for more examples.

Cheers, Rich

Headings

Thomas asked:

Dear Doctors,

you covered the new header tag in an article. The header tag should contain a heading element, like h1-6. So far so good, but how do I structure my headings further on. E.g. I’ve got this:

<article>
	<header>
		<h1>My major heading</h1>
		<h2>Subheading</h2>
		Abstract text...
	</header>
	... lorem ipsum ....
	<hX>Heading within my article</hX>
	... dolor sit amet ...
	<hX+1>Subheading in my article</hX+1>
</article>

Which heading-level would be appropriate in my example? h1 because it starts again? or h3 because it continues?

Thank you

If the first <hX> is a new subheading and not related to the <h2> already there, then <hX> would be an <h2>. Then <hX+1> would be an <h3> if it is a subheading of the above <h2>.

However, if you’re splitting the article into sections, then you could use an <h1> each time. See our article on the section element for more.

Thanks, Tom

Got a question for us?

That wraps up this round of questions! If you’ve got a query about the HTML5 spec or how to implement it, you can get in touch with us and we’ll do our best to help.

Share and Save:

Your Questions Answered 9 originally appeared on HTML5 Doctor on May 14, 2010.

Ruby text is a short annotation for some base text. It’s typically used to give pronunciation guidance in a phonetic script for kanji in Chinese, Japanese, and Korean (CJK) languages. It’s named after an old printers’ term for the very small size of 5.5 points.

The ruby element allows spans of phrasing content to be marked with ruby annotations.

W3C Specification

As the name implies, ruby text is small, displayed by default above the base text in horizontal text and to the right in vertical text. Browsers without <ruby> support put the ruby text inline after the base text.

These are the elements used in creating ruby text in HTML5:

• <ruby> — an inline element that contains base text with ruby annotations
• <rt> — ruby text, coming after the base text it defines
• <rp> — ruby parentheses, an element used to wrap opening and closing parentheses around <rt> ruby text. These are for user agents that don’t support ruby text, so that it makes sense when displayed inline. Browsers that support <ruby> hide <rp> via {display:none;}.

Examples

If you’ve never seen ruby in action you’re probably wondering what I’m talking about, so here are some examples:

rt, rp {font-size: 60%;} /* = Webkit value */

rt, rp {display: inline; font-size: 100%;}

Code samples and output

These code samples (with notes and CSS) are also available separately.

<ruby> in Japanese — furigana and rōmaji

Using <ruby> without <rp>

<ruby>攻殻<rt>こうかく</rt>機動隊<rt>きどうたい</rt></ruby>

Using <ruby> with <rp>

<ruby>攻殻<rp>（</rp><rt>こうかく</rt><rp>）</rp>機動隊<rp>（</rp><rt>きどうたい</rt><rp>）</rp></ruby>

Nested <ruby> for multiple ruby texts

<ruby><ruby>攻<rp>（</rp><rt>こう</rt><rp>）</rp>殻<rp>（</rp><rt>かく</rt><rp>）</rp>機<rp>（</rp><rt>き</rt><rp>）</rp>動<rp>（</rp><rt>どう</rt><rp>）</rp>隊<rp>（</rp><rt>たい</rt><rp>）</rp></ruby><rp>（</rp><rt>Kōkakukidōtai</rt><rp>）</rp></ruby>

Japanese glossary

Furigana is the name given to using hiragana phonetic script beside words written in kanji to aid reading. It’s used extensively in education for learners of Japanese, and in reading material for children. It’s also sometimes used when writing kanji a literate adult may not be able to read.

Rōmaji is the romanisation of Japanese into the latin alphabet. Rōmaji is generally used for those who don’t know Japanese, especially in signage and tourism information.

<ruby> in Chinese — Pīnyīn and zhùyīn fúhào (bopomofo)

Ruby is used to some extent in China (pīnyīn), and more so in Taiwan (zhùyīn fúhào), especially in textbooks and signage.

Pīnyīn

<p>The <b>Grass mud horse</b> — <ruby>草泥馬<rp>(</rp><rt>Cǎo Ní Mǎ</rt><rp>)</rp></ruby> — is … characterised as “lively, intelligent and tenacious”. However, their existence is said to be threatened by the “river crabs” — <ruby class="styled">河蟹<rp> (</rp><rt>héxiè</rt><rp>) </rp></ruby> — which are invading their habitat.</p>

Zhùyīn fúhào

<ruby><ruby>世<rp>（</rp><rt>ㄕˋ</rt><rp>）</rp>上<rp>（</rp><rt>ㄕㄤˋ</rt><rp>）</rp>無<rp>（</rp><rt>ㄨˊ</rt><rp>）</rp>難<rp>（</rp><rt>ㄋㄢˊ</rt><rp>）</rp>事<rp>（</rp><rt>ㄕˋ</rt><rp>）</rp>只<rp>（</rp><rt>ㄓˇ</rt><rp>）</rp>怕<rp>（</rp><rt>ㄆㄚˋ</rt><rp>）</rp>有<rp>（</rp><rt>ㄧㄡˇ</rt><rp>）</rp>心<rp>（</rp><rt>ㄒㄧㄣ</rt><rp>）</rp>人<rp>（</rp><rt>ㄖㄣˊ</rt><rp>）</rp></ruby><rp> （</rp><rt>Anything can be done with enough perseverance</rt><rp>）</rp></ruby>

Chinese glossary

Pīnyīn is a romanised phonetic system for Chinese, generally written above or after the word. Bopomofo (Zhùyīn fúhào) is a phonetic script for transcribing Chinese, especially Mandarin. It is generally written (in both horizontal and vertical scripts) vertically to the right of each hanzi character.

Korean ruby

While the use of hanja (kanji) is decreasing in South Korea, they are still used for disambiguation and proper names.

<ruby>한자<rp>(</rp><rt>漢字</rt><rp>)</rp></ruby>

Korean glossary

Hangul is the Korean script, and hanja is Korean for Chinese characters. Traditionally written Korean used hanja, but now it’s mainly used in academic texts and occasionally for disambiguation.

Using <ruby> for English

Not everyone is using East Asian languages, but any short annotation is (theoretically) applicable. While English doesn’t typically have pronunciation guidance, phonetic annotations are used in dictionaries:

<ruby><strong>cromulent</strong> <rp>(</rp><rt>crôm-yü-lənt</rt><rp>)</rp></ruby>

The ruby element and her hawt friends, rt and rp originally appeared on HTML5 Doctor on May 11, 2010.

We’re back with more of your questions (and our answers) about HTML5. In this article, we’ll discuss using a <footer> at the top of your markup, how to skip to certain parts of a video, styling form elements and attributes, and more.

HTML5 <footer> on top

David asked:

Hi!

I wonder if it possible to put the footer on top such as www.perfectfools.com with HTML5 and still make the HTML validate.

Thanks a lot and best regards!

David

HTML elements should always describe their content, so if you think that <footer> is most suitable for your content, then you’re absolutely entitled to use it. Despite its name, <footer>’s position is in no way restricted — visually or ordinally — within a document.

Cheers, Rich

Skip to certain parts of a video file

John Paul asked:

Hello

supposing I have a very long video file in an accompanying video element, without using the controls, how do I skip to certain time stages through the API? Much as one would on a DVD menu, for example.

Apologies if this has been asked already.

JP

You can achieve this using JavaScript and data attributes. Check out these articles from Bruce Lawson and Patrick Lauke from Opera. They’ve used data attributes to add subtitles, but you could just as easily use the attributes to jump to specific parts of a video.

• Introduction to HTML5 video
• Accessible HTML5 video with scripted captions

For example, set data-start and data-end attributes on your <video> element. You can then use JavaScript to read the attribute values, set the current position of the video using the currentTime attribute, start playing the video via the play() method, and even stop playing the video by listening for the timeupdate event and stopping the video with pause() once it’s reached a specified time. See the spec for the HTMLMediaElement object for more details.

Cheers, Rich

In addition to this, the recent addition of the track element will make this more easily achievable. We will cover the track element in more detail soon.

<h1>s within navigation links

Benjamin asked:

Hey,

I’m currently doing up the new version of my website, and decided to do it in HTML5.

One area I’m confused about is whether or not for navigation links I should be using a h1 or h2 element.

For example:

<nav id="nav-actions">
    <header>
        <h1><span class="title">Actions</span></h1>
    </header>
    <ul>
        <li><a href="#"><span class="title">Sitemap</span></a></li>
        <li><a href="#"><span class="title">Login</span></a></li>
        <li id="action-search"><a href="#"><span class="title">Search</span></a></li>
        <li id="action-enquire"><a href="#"><span class="title">Enquire</span></a></li>
    </ul>
</nav>

Should those span.title elements be wrapped in a h2? My thoughts on why this would be required is for an outline, as navigation should appear in the outline right?

Thanks a bunch.

In theory, yes, navigation should appear in the outline. I personally don’t think it should require a heading, and I know there have been requests to the developers of the outline algorithm to make <nav> show as a ‘Navigation’ element rather than ‘untitled section’.

If you want to use a heading within your <nav> element, using an <h1> would be fine. You don’t really need the <header> element in there too. The outline would be calculated correctly without it. With current browser implementations, however, I don’t think it would make much difference if you used an <h2>.

You don’t need the <span> elements in the <h2>s. They aren’t required in the outline unless they’re providing a table of contents for the document.

I hope that answers your question. We plan to write an article regarding outlining soon.

Cheers, Rich

Styling supported HTML5 form elements and attributes

Mike asked:

First off, I wanted to say I really appreciate the service this site is doing. I have found this site to be a very valuable resource and is always the first place I look when I have a question about implementing HTML5.

How do I style/edit/change the UI generated feedback for the new HTML5 form elements and attributes. For example, In Opera, is there a standard CSS notation to style the error message so that it doesn’t necessarily show up under the field in red? Where in the DOM is it inserted? Is the message for a required field customizable? Finally, is this information specified in the HTML5 spec or are the implementation details left up to the browsers?

There is currently no way to use CSS to style error messages. As the HTML5 spec isn’t finished yet, it’s a bit early to start specifying new CSS.

The HTML5 spec defines no UI requirements regarding how browsers should display messages.

You can override a browser’s default behaviour with JavaScript. I’m not a scripter, but I reckon you would need to attach an event handler to the error event and have the handler cancel the default action and show a custom error message. I think that as long as you call evt.preventDefault() within the event handler, it should prevent showing the default error message. Then you can add an element into the DOM and style it as you wish, with the default error handling as a fallback for those without JavaScript. If anyone gives this a go and gets it working, we’d be very interested to see the results.

Ta, Bruce

Section headers

Tibor asked:

Hi. I would like to know, how to use section’s headers. Is this code correct?

<aside>
	<h1>header 1</h1>
</aside>
<article>
	<h1>header 2</h1>
</article>

or I have to use header element inside every aside, article, section etc.

<aside>
	<header>
    	<h1>header 1</h1>
	</header>
</aside>
<article>
	<header>
    	<h1>header 2</h1>
	</header>
</article>

Tibor

Your first example is correct. You only need <header> to group items within a header. If the header contains only a single <h1>–<h6> element, you don’t need to wrap it in a <header>.

Thanks, Bruce

Got a question for us?

That wraps up this round of questions! If you’ve got a query about the HTML5 spec or how to implement it, you can get in touch with us and we’ll do our best to help.

Share and Save:

Your Questions Answered #8 originally appeared on HTML5 Doctor on May 5, 2010.