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.

One of the new elements defined in HTML5 is <hgroup>, used for grouping titles with their associated subtitles. But why do we need <hgroup> when we’ve already got the <header> element? In this article, we’ll do our best to answer that question.

What is the <hgroup> element?

Here’s what the spec says about <hgroup>:

The hgroup element is typically used to group a set of one or more h1-h6 elements — to group, for example, a section title and an accompanying subtitle.

So what does that mean?

<hgroup> acts as a wrapper for two one or more related heading elements possibly contained within a <header> element. It can only contain a group of <h1>–<h6> element(s), and it should be used for subtitles, alternative titles, and tag lines.

The easiest way to demonstrate proper use of <hgroup> is through some examples. Thanks to Dr. Oli for letting us use his examples.

An article with one title

The title consists of a single <h1>, so neither <hgroup> nor <header> is required:

<article>
  <h1>Title goes here</h1>
  <p>Lorem Ipsum dolor set amet</p>
</article>

An article with a title and metadata

Here we’re using <header> to group the title and associated metadata, so an <hgroup> is not required:

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

An article with a title and subtitle

An <hgroup> contains the title and subtitle of the article:

<article>
  <hgroup>
    <h1>Title goes here</h1>
    <h2>Subtitle of article</h2>
  </hgroup>
  <p>Lorem Ipsum dolor set amet</p>
</article>

An article with a title, subtitle and metadata

An <hgroup> contains the title and subtitle of the article, and then a <header> contains the metadata and the <hgroup>:

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

Real world examples

On Alex Gibson’s MiniApps, he uses <hgroup> to include a tag line after the main “MiniApps” heading. (This is also what we’ve done on this site if you view the source.)

So why use <hgroup>?

It’s all about the document outline. When grouping headings in an <hgroup> element, the outline algorithm will mask the lowest level all but the highest level heading in the group from the resulting document outline. Using MiniApps as an example again, in his markup (although this is simplified), Alex uses:

<header>
  <hgroup>
    <h1><a href="/">Mini Apps</a></h1>
    <h2>Web applications for iPhone, Android & other mobile platforms</h2>
  </hgroup>
</header>

The <hgroup> contains both <h1> and <h2> elements, but the outliner only includes the <h1>. This is illustrated in the image below. (Please ignore the “untitled section” as well. This is caused by the nav element, and a change request has been submitted to address this.)

We’ll be covering document outlines in another article, so I won’t go into detail here. You can test your own pages in the HTML5 Outliner to ensure that you’re using the heading elements within <hgroup> correctly.

Summary

In this article, we’ve demonstrated how to use the <hgroup> element effectively. To recap:

• If you have a simple title with a single heading element (<h1>–<h6>), you do not need an <hgroup>.
• If you have a title with subtitle(s) or tag lines (i.e., more than one consecutive <h1>–<h6>), group them in an <hgroup>.
• If you have a title with subtitle(s) and other metadata associated with the section or article, place both the <hgroup> and the metadata within a single <header> element.

Let us know how you’re using <hgroup> in your HTML5 projects!

The hgroup element originally appeared on HTML5 Doctor on March 23, 2010.

Since the HTML5 specification is not yet final, we can expect changes to improve on the good bits and cut out the bad bits. aside — a misunderstood good bit — has now been tweaked based on feedback from the web development community. In this article, we’ll take a look at what’s changed.

Aside redefined

When we previously discussed aside in “Understanding Aside“, its definition suggested that it should be used for content tangentially related to the content surrounding it, such as related reading links and glossaries. It did not appear to be an appropriate element for holding secondary content related to the site as a whole, typically known as a “sidebar”.

From the comments here and elsewhere, you can see this definition was not accepted by developers. The spec writers listened, and aside is now acceptable for secondary content when not nested within an article element.

Examples of aside in two different contexts

With the new definition of aside, it’s crucial to remain aware of its context. When used within an article element, the contents should be specifically related to that article (e.g., a glossary). When used outside of an article element, the contents should be related to the site (e.g., a blogroll, groups of additional navigation, and even advertising if that content is related to the page).

The two uses of aside can be best illustrated with an example:

<body>
  <header>
    <h1>My Blog</h1>
  </header>
  <article>
    <h1>My Blog Post</h1>
    <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
    eiusmod tempor incididunt ut labore et dolore magna aliqua.</p>
    <aside>
      <!-- Since this aside is contained within an article, a parser
      should understand that the content of this aside is directly related
      to the article itself. -->
      <h1>Glossary</h1>
      <dl>
        <dt>Lorem</dt>
        <dd>ipsum dolor sit amet</dd>
      </dl>
    </aside>
  </article>
  <aside>
    <!-- This aside is outside of the article. Its content is related
    to the page, but not as closely related to the above article -->
    <h2>Blogroll</h2>
    <ul>
      <li><a href="#">My Friend</a></li>
      <li><a href="#">My Other Friend</a></li>
      <li><a href="#">My Best Friend</a></li>
    </ul>
  </aside>
</body>

Conclusion

The aside element can now represent secondary content when used outside of an article. Keep in mind that aside — and, more generally, secondary content — does not necessarily mean “sidebar”. The style of the content should not dictate the use of the element. For content that is not the primary focus of an article (or page) but is still related to the article (or page), aside is what you need, regardless of its visual design.

Share and Save:

Aside Revisited originally appeared on HTML5 Doctor on October 28, 2009.

We doctors are a bunch of chums using HTML5 and writing about how we do it. Apart from spurious requests for medical advice, the questions we receive most are about using the section element, and we realise that we’ve been using the section element incorrectly all this time.

Sorry.

What we’ve been doing wrong is using section to wrap content in order to style it, or to demarcate the main content area from the nav, header, footer etc. These are jobs for div, not section.

The section spec says

The section element represents a generic document or application section…The section element is not a generic container element. When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead.

section is a blob of content that you could store as an individual record in a database. It generally looks like this (and note that the heading goes inside the section element, not immediately before it):

<section>
<h1>Any level of heading</h1>
rest of the content
</section>

With very few exceptions, section should not be used if there is no natural heading for it. Check your work in the HTML 5 outiner tool. If you see any instances of “untitled section” that corresponds to a section, you’re probably doing it wrong. (It’s fine for a nav or aside element to be untitled, however).

Section is also the most generic of the sectioning elements. Make certain that you don’t really need an article, which is defined as

a composition that forms an independent part of a document, page, application, or site. This could be a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, an interactive widget, or any other independent item of content

Rules of thumb for using section

Of course, there are always exceptions, but these should give useful guidance for 99% of cases:

• Don’t use it just as hook for styling or scripting; that’s a div
• Don’t use it if article, aside or nav is more appropriate
• Don’t use it unless there is naturally a heading at the start of the section
• The revised spec (as of 16 September) says:
  

  Authors are encouraged to use the article element instead of the section element when it would make sense to syndicate the contents of the element.

  As blogposts and comments are often syndicated (by being pulled into other blogs or being linked via twitter, reddit etc) they should be articles.

Thanks to Opera’s Lachlan Hunt for fact-checking this article. Please also note that we haven’t yet changed the WordPress theme to get rid of extra sections, so for now please do as we say and not as we do!

Related Posts:

• September HTML5 spec changes
• Designing a blog with html5
• The small & hr elements
• Your Questions Answered #3
• HTML 5 + XML = XHTML 5

Share and Save:

The section element originally appeared on HTML5 Doctor on September 11, 2009.

]]> http://html5doctor.com/the-section-element/feed/ 82 http://html5doctor.com/your-questions-answered-1/ http://html5doctor.com/your-questions-answered-1/#comments Mon, 06 Jul 2009 10:59:36 +0000 Richard Clark http://html5doctor.com/?p=390 HTML 5 and asking about what you can and can't do as well as the pro's and cons of the specification. In this post we're going to cover a few of the questions we've received that don't require a full post answer but still need to be addressed.]]>

One week on since our official launch and we’ve been overwhelmed by your response to the site. It’s great to see a large number of you wanting to get involved with the discussion relating to HTML 5 and asking about what you can and can’t do as well as the pro’s and cons of the specification.

In this post we’re going to cover a few of the questions we’ve received that don’t require a full post answer but still need to be addressed. We’ll post more answers everytime we’ve collated a bunch of questions so don’t be afraid to ask, however groundbreaking or insignificant it might be. Ok here we go for starters…

Automated Conversion?

Andy Mabbett wrote to ask:

Are there (or will there be) any automated or semi-automated tools which will take my (valid) HTML 4.01 Strict documents and convert them to HTML5?

While we don’t know about any specific conversion tools for converting to HTML 5 from HTML 4.01. There are several articles (see below) describing how you can name your classes more semantically in preparation for using HTML 5.

• More on developing naming conventions, Microformats and HTML5
• Preparing for HTML5 with Semantic Class Names
• HTML5 id/class name cheatsheet

A final point on this is that I’m not sure that it would be wise to have a converter in order to move from HTML 4.01 to HTML 5, a machine however clever will not really be able to understand the true meaning of <aside> or <figure> for example. I’d be interested to hear other peoples thoughts on this though?

When should I start using HTML 5?

James asked us (presumably a little tongue in cheek):

Dear Doctor,

When will I know that it is time to start using HTML5 “for real”? Will there be an announcement?

yours etc,
James

Now I’d love there to be an official annoucement, in fact I might just announce it now! You can all start using HTML 5 today. There I said it, I feel so much better now. Seriously though, there is no reason for you not to start using HTML 5 now in sites you’re developing. I’m not saying that you have to use it religiously, but at you should at least start thinking about it in your development roadmaps. We can see on our sister site that there are a number of sites using HTML 5 “in the wild”. The amount of implementation varies greatly (some including <div>’s around their <header> elements for styling purposes for example) but they have begun to incorporate HTML 5 right now.

Lastly, Molly recently gave a talk at @media which touched upon this subject, she told us that

Implementation trumps specification

which I happen to firmly believe, after all CSS 2.1 isn’t a formal specification yet but almost everyone is using it. If you’re not sure where to start then I suggest taking a look at what browser implementations are currently like, which is where this Wiki from the WHATWG comes in. Hope that answers your question James.

Main Body

Darren asked:

How do I markup the main body of a page, are there <content> tags? Can I serve a SWF Flash file using <VIDEO> tags?

Regards Darren

There isn’t a <content> tag (element), the most appropriate element for that would be <section>, however if only a single article is contained in that area you should use <article>.

As for the second part to your question, you *can’t* use a SWF file natively as the source to the <video> tag, or FLV file for that matter. However, for the foreseeable future you’re still going to need to embed flash for video, via nesting the flash within the <video> tag.

First you’ll use the <video> with nested source elements to fall through the different supported codecs. Then when all else fails, particularly for IE, you’ll serve up the flash video via the <object> and <embed> combo. This is because IE8 and lower doesn’t support the <video> you’re going to need to fall back on something that works.

Make sure you read Tom’s article about the <video> element, but you should also find this article on Video for Everybody useful to see how to degrade through the codecs.

More articles!

Although not really a question I wanted to drop this in, August wrote to tell us:

The <aside> article is awesome. Great explanation of a very semantic HTML5 element. More of those, please!

Thanks for the great feedback August, we’re happy to help, rest assured we’ve got plenty of articles lined up along those lines, in fact I know we’ve got a few crackers lined up for the next couple of weeks, so watch this space.

And finally…

If your question hasn’t been answered in this post or we haven’t got back to you directly then it’s more than likely that we’ll be covering it soon in a more detailed post so be sure to check back or subscribe to the RSS feed for all future articles.

Related Posts:

• Your questions answered #2
• Your Questions Answered #6
• Your Questions Answered #8
• Video: the track element and webM codec
• The video element

Share and Save:

Your questions answered #1 originally appeared on HTML5 Doctor on July 6, 2009.

]]> http://html5doctor.com/your-questions-answered-1/feed/ 8 http://html5doctor.com/designing-a-blog-with-html5/ http://html5doctor.com/designing-a-blog-with-html5/#comments Tue, 30 Jun 2009 14:00:21 +0000 Bruce Lawson http://html5doctor.com/?p=47

Much of HTML 5’s feature set involves JavaScript APIs that make it easier to develop interactive web pages but there are a slew of new elements that allow you extra semantics in your conventional Web 1.0 pages. In order to investigate these, let’s look at marking up a blog.

Firstly what we’ll do is use the header, footer, and nav elements to mark up the broad structure of the page. We’ll make the blog comments form much smarter by using the new data types and built-in validation available in HTML 5-aware browsers.

Then we’ll do some work on the guts of the page, using HTML 5’s article elements to better mark up blog posts and comments and show how to use the section elements to better structure accessible hierarchical headings on sites that are CMS-driven. As blogs are chronologically ordered, we’ll see what HTML 5 offers us for representing dates and times.

So take the phone of the hook, and make a cup of tea and we’ll get started.

Setting the DOCTYPE

HTML 5, when used as plain HTML rather than its XHTML 5 sibling doesn’t need a DOCTYPE. But all browsers do, otherwise they go into Quirksmode, which you don’t want: the collision of HTML 5 and Quirksmode is like matter and anti-matter meeting, and will cause a negative reality inversion that will make your underwear catch fire.

You’ve been warned, so at the top of your document, you need the line <!DOCTYPE html>.

Some sites “use” HTML 5, when in actual fact all they’ve done is take their existing code and change the DOCTYPE. That’s fine and dandy if you’ve been using valid, semantic code as HTML 5 is very similar to valid HTML 4.01. Eric Meyer mentions small differences like “not permitting a value attribute on an image submit”, and there are a few differences between the languages, summarised in the document HTML 5 differences from HTML 4.

However, I don’t want simply to rebadge my existing code, but to use some of the new structural elements now.

Using some new structural elements

My blog – like millions of others – has a header denoted by <div id="header">, a footer <div id="footer">, some articles (wrapped by an area called “content”, <div id="content">) and some navigation (wrapped up in an area called “sidebar” <div id="sidebar">). Most sites on the Web have similar constructs, although depending on your choice they might be called "branding" or "info" or "menu", or you might use the equivalent words in your own language.

Although these all have very different functions within the page, they use the same generic div in the markup. as HTML 4 has no other way to code them. HTML 5 has new elements for distinguishing these logical areas: header, nav, footer and friends. (There’s more on this in an artice by Lachlan Hunt on A List Apart: A Preview of HTML 5.)

The overall aim is to replace this structure:

with this:

It’s a simple matter to change the HTML divs into the new elements. The only difficulty I had was deciding which element to use to mark up my sidebar, as it also includes a search field and “colophon” information as well as site-wide navigation. I decided against the aside element, as the spec says it “represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content”, but it’s nevertheless content rather than navigation. So I decided to go for the nav element as the closest fit.

I’ve wrapped the main content in a section element (previously I’d kept it as a div). section is defined in the spec

The section element represents a generic document or application section. A section, in this context, is a thematic grouping of content, typically with a heading, possibly with a footer.

Please note: I no longer recommend wrapping the whole content area in a section element, and suggest that you use a div element. Read more about using section appropriately.

In this case, the “generic document section” is that of main content. I’ve retained an id so that a skip links feature will work, although I hope that in the future, assistive technology will offer an automatic way for people to go to the first section or article.

My fellow HTML 5 doctor, Remy Sharp, also notes that if you retain the div, Internet Explorer without JavaScript would style the div, but none of the other content, making the site very hard to read.

New form attributes

As well as the main structural item on the page, I’ve added some new attributes on input elements in the comments form.

HTML 5 was designed to reflect what developers actually do rather than to reflect a philosophical purity, and that’s very clearly manifested in the new attributes which mean the browser takes up much of the work currently done by developers re-inventing validation routines in JavaScript. (Extending forms functionality was how the HTML 5 spec began).

So I amended the email input field in the comments to be input type="email" which means that when the user submits the form, an HTML 5-aware browser will use built-in validation routines to check that it’s in the correct format, without any JavaScript. Check it out in the current version of Opera, as that the only full implementation at the time of writing (June 2009), and note that it also adds a “mail” icon in the input field as a cue to the user.

There are similar input validation routines triggered by some of the new input types, such as url (which I use on the field that asks for the user’s web address), number and pattern which compares the input with an arbitrary regular expression.

Another good example is input type="date", which pops up a calendar widget/ date picker when the user focusses on the input field. You can test the date picker, or here’s a screenshot from Opera 9.6:

A very useful new attribute I used on both input fields for commenter’s name and email address, and the comment textarea was type="required" which generates a message on submission if the fields are left blank. Each different localisation of a browser would need to have a different message, and it’s not (so far) customisable by the developer.

The good thing with all this new form fabulousness is it’s all formed around new attributes on an exisiting element, so people using older browsers just see a plain old input field.

A note on screenreaders and HTML 5

I hope screenreaders are ready for these new interactions; I asked the html 5 group to formally invite screenreader vendors to participate in the specification; to my knowledge, none have done so.

Laying out the new elements

It’s not too hard to layout the new elements. In all the non-IE browsers, you can lay out anything using CSS – even a nonsense element. One gotcha is that that the current crop of browsers have no “knowledge” of these elements, although support is improving all the time.

All browsers have default settings for the elements they “know about”—how much padding, margin they element gets, does it display as a block or inline?. (Here’s a sample default stylesheet.) Unless over-ridden by CSS, these defaults apply. But the browsers don’t know about header, nav and the like, so have no defaults to apply to them.

I got terrible rendering oddities until I explicitly told the browsers

header, footer, nav, article {display:block;}

IE layout

There’s one gotcha about styling HTML 5 pages in IE: it doesn’t work. You can force it to quite easily with a JavaScript hack document.createElement('element name'). (Lachlan Hunt gets to the bottom of why IE needs this.)

For your convenience, Remy Sharp has written an HTML 5 enabling script which I use in the header to conjure all the missing elements into existence all at once.

But let’s be clear: this won’t work if your IE user doesn’t have JavaScript turned on. How much of that’s a big deal that is for you to decide. Pragmatically, it seems to me that the sites that will benefit the most from HTML 5’s new “Ajax”-style features, such as drag-and-drop, are the sites that currently have no hope of working without JavaScript.

Firefox 2 and Camino 1 layout

Firefox 2 and Camino 1 both use Gecko 1.9 which has a bug and so gets grumpy if you don’t serve the page as XHTML. (Go figure; that’s almost enough to trigger a negative reality inversion and you know how bad that can be). However, Firefox and Camino users upgrade frequently so Firefox is in version 3, while Camino 2 beta is out, so the problem will soon cease to exist. (Read more at How to get HTML5 working in IE and Firefox 22 by Remy Sharp.)

What’s the point of those new structural elements?

Well, they add semantics to the page. The browser now knows which area of your site is the header or the footer because there are header and footer elements, whereas div might be called “branding” and “legal”, or even “en-tete” and “pied-de-page” or “kopfzeile” and “fusszeile“.

But so what?

Robin Berjon expressed it beautifully in a comment on A List Apart:

Pretty much everyone in the Web community agrees that “semantics are yummy, and will get you cookies”, and that’s probably true. But once you start digging a little bit further, it becomes clear that very few people can actually articulate a reason why. So before we all go another round on this, I have to ask: what’s it you wanna do with them darn semantics?

The general answer is “to repurpose content”. That’s fine on the surface, but you quickly reach a point where you have to ask “repurpose to what?” … I think HTML should add only elements that either expose functionality that would be pretty much meaningless otherwise (e.g. canvas) or that provide semantics that help repurpose for Web browsing uses.

In my view, there are a couple of things I want to do with those semantics. The first is for search engine use; it’s easy to imagine Messrs Google or Yahoo! giving lower weighting to content in footer elements, or extra weight to content in the header. The second reason is to make the site navigable for people with disabilities. People with learning difficulties might instruct their browser always to put the articles before the navigation, for example. User agents might very well have a keyboard shortcut which jumped straight to the nav for example, or jumped straight past the navigation, in a programmatic implementation of “skip links“.

Which brings me to…

Further refining the HTML 5 structure

The blog home page

An interesting thing about a blog homepage is that there are generally the last 5 or so posts, each with a heading, a "body" and data about the post (time, who wrote it, how many comments etc.) and usually a link to another page that has the full blog post (if the homepage just showed an excerpt) and its comments.

HTML 5 has an article element which I use to wrap each story:

The article element represents a section of a page that consists of a composition that forms an independent part of a document, page, or site. This could be a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, or any other independent item of content.

Let’s look in more detail at the guts of how I mark up each blogpost.

Anatomy of a blog post

The wrapper is no longer a generic div but an article. Within that is a header, comprising a heading (the title of the blogpost) and then the time of publication, marked up using the time element.

Then there are the pearls of wit and wisdom that consitute each of my posts, marked up as paragraphs, blockquotes etc., and is pulled unchanged out of the database. Following that is data about the blog post (category, how many comments) marked up as a footer and, in the case of pages that show a single blogpost, there are comments expressing undying admiration and love. Finally, there may be navigation from one article to the next.

Data about the article

Following the content there is some “metadata” about the post: what category it’s in, how many comments there are. I’ve marked this up as footer. I previously used aside which “represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content” but decided that it was too much of a stretch; data about a post is intimately related.

footer is a much better fit: “A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.” 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."

Comments

I’ve marked up comments as articles, too, as the spec says that an article could be “a user-submitted comment”, but nested these inside the parent article. The spec says

When article elements are nested, the inner article elements represent articles that are in principle related to the contents of the outer article. For instance, a Web log entry on a site that accepts user-submitted comments could represent the comments as article elements nested within the article element for the Web log entry.

These are headed with the date and the time of the comment and name of its author—if you want, you can wrap these in a header, too, but to me it seems like markup for the sake of it.

Times and dates

Most blogs, news sites and the like provide dates of article publication.

Microformats people, the most vocal advocates of marking up dates and times, believe that computer-formatted dates are best for people: their wiki says “the ISO8601 YYYY-MM-DD format for dates is the best choice that is the most accurately readable for the most people worldwide, and thus the most accessible as well”. I don’t agree (and neither do candidates in my vox pop of non-geeks, my wife, brother and parents).

I do agree with the microformats people that hidden metadata is not as good as visible, human-readable data and therefore elected not to use the pubdate attribute of article.

Therefore I’ve used the HTML 5 time element to give a machine parsable date to computers, while giving people a human-readable date. Blog posts get the date, while comments get the date and time.

The spec is quite hard to understand, in my opinion, but the format you use is 2004-02-28T15:19:21+00:00, where T separates the date and the time, and the + (or a -) is the offset from UTC. Dates on their own don’t need a timezone; full datetimes do. Oddly, the spec suggests that if you use a time without a date, you don’t need a timezone either.

There’s considerable controversy over the time element at the moment. Recently one of the inner circle, Henri Sivonen, wrote that it’s for marking up future events only and not for timestamping blogs or news items: “The expected use cases of hCalendar are mainly transferring future event entries from a Web page into an application like iCal." This seems very silly to me; if there is a time element, why not allow me to mark up any time or date?

The spec for time does not mention the future event-only restriction: "The time element represents a precise date and/or a time in the proleptic Gregorian calendar" and gives three examples, two of which are about the past and none of which are "future events". Although the spec doesn’t (currently) limit use of the element, it does limit format to precise dates in "the proleptic Gregorian calendar". This means I can mark up an archive page for "all blog posts today" using time, but not "all July 2008 posts" as that’s not a full YYYY-MM-DD date. Neither can you mark up precise, but ancient dates, so the date of Julius Ceasar’s assassination, 15 March 44 BC is not compatible.

I don’t expect this to be resolved. If you think as I do, feel free to mail the Working Group to express your feeling!

Hopefully, this brief article (geddit?) has given you a quick overview of how to use some of the new semantic elements. Let me know what you think!

Related Posts:

• Aside Revisited
• Native Drag and Drop
• The time element (and microformats)
• The section element
• Draw attention with mark

Share and Save:

Designing a blog with html5 originally appeared on HTML5 Doctor on June 30, 2009.

]]> http://html5doctor.com/designing-a-blog-with-html5/feed/ 140 http://html5doctor.com/understanding-aside/ http://html5doctor.com/understanding-aside/#comments Fri, 19 Jun 2009 13:00:21 +0000 Mike Robinson http://html5doctor.com/?p=154

HTML 5 offers a new element to mark additional information that can enhance an article but isn’t necessarily key to understanding it. However, in the interpretation of <aside> there lies confusion as to how it can be used, and with that there is demand for the Doctor to step up and clear the air. In this article I will look at what <aside> was created for, including sample uses and how not to use this useful, misunderstood element.

First, a look at how the HTML 5 specification defines <aside>:

The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.

What can often trip-up someone reading the specification is the use of the word “sidebar”. I will go into detail about this later in the article, for now you should be aware that what is said there might not quite mean what you first think. Content within an <aside> should be stand-alone information that is related to the article in context. If your <aside> content meets this requirement, then you have a useful element to not only semantically wrap that content but to even hook CSS styles on.

How strict should this relationship be? Very. Good <aside> content examples include pull-quotes, a glossary or even related links.

Example Uses

As suggested in the specification, a pull-quote is an excellent example of a piece of content that is separate from the main article body but still related. Points of interest highlighted.

<article>
    <header>
        <h1>Lorem Ipsum Dolor Sit Amets</h1>
    </header>
    <p>Aliquam erat volutpat. Vestibulum eleifend pellentesque urna, at
    sodales est faucibus sit amet. Praesent in mi dui. <q>Aliquam sed
    bibendum nisl. Mauris pharetra enim sit amet ipsum dictum placerat. Sed
    lacinia pulvinar iaculis. Nam sit amet hendrerit purus.</q> Sed a urna
    laoreet lorem pulvinar fermentum. Aenean vel luctus libero. Ut tincidunt
    metus sagittis ante viverra feugiat.</p>
    <aside>
        <q>Mauris pharetra enim sit amet ipsum dictum placerat.</q>
    </aside>
    <p>Nulla quis lacus non quam luctus vestibulum. Pellentesque imperdiet
    risus gravida ante consectetur fermentum. Vivamus et est nec risus volutpat
    elementum. Ut faucibus, lectus consectetur volutpat dapibus, quam diam
    luctus enim, vitae mollis enim purus non ante.</p>
</article>

For more about the <header> element see Richard’s article, “The <header> Element.

On a styled web page or, more common, in a printed article this would be represented visually as a highlighted quote to the side of the main article. This <aside> is related to the content but does not need to be part of the article body as it can be understood without the extra information, or in this case without the duplicate quote.

Another example would be a glossary of terminologies used in an article:

<article>
    <header>
        <h1>Web Technologies</h1>
    </header>
    <p>Curabitur dignissim lorem a CSS diam posuere tempor. Nam hendrerit,
    eros vel condimentum tempor, ipsum justo cursus justo, quis vestibulum
    turpis turpis sit amet tellus. Quisque quis PHP magna eget ipsum faucibus
    bibendum at non diam. Sed sapien est, cursus ac ullamcorper id, egestas vel
    urna JavaScript. Nullam aliquam dolor vitae quam pharetra auctor.</p>
    <aside>
        <dl>
            <dt>CSS</dt>
            <dd>A set of standards for styling documents presented on the
            World Wide Web.</dd>
            <dt>PHP</dt>
            <dd>A server-side scripting language suited to dynamic HTML document
            generation for the web.</dd>
            <dt>JavaScript</dt>
            <dd>A client-side scripting language used for manipulating HTML documents
            within a browser.</dd>
        </dl>
    </aside>
</article>

Incorrect use of <aside>

It is easy to confuse this element for something it isn’t, and as mentioned earlier the definition of <aside> can trip-up a few developers. The most common misconception of how this element should be used is for the standard sidebar. While there is usually a degree of relation between sidebar content and the content in an article, it is not enough to be considered fit for an <aside>. Navigation, ads, search boxes, blogrolls and so on are not directly related to the article and therefore do not justify the use of an <aside>.

In the definition of <aside> it is key to note that it refers to sidebars in printed media, such as a magazine or leaflet. A “sidebar” in a magazine might contain additional notes on the article in context, translating this to HTML 5 would consider this an <aside>. If the printed article on PHP had an ad for “Superior, Cheap, Web Hosting” as a sidebar, this would not be classified as an <aside>. In such cases, look at other elements for more semantic mark-up.

Closing Thoughts

Like any HTML element, when used correctly the <aside> element can be very useful in semantically marking-up page content. An <aside> can be used to enhance an article with additional information, or highlighting parts that the reader may find interesting. Asides are stand-alone, non-essential as part of an article but when used correctly it can be an extra level of information for your content. Don’t try to force content into an <aside>, if it’s not tangentially related to the article then it shouldn’t be there. HTML 5 offers many new elements to mark-up your web pages, use them wisely.

Related Posts:

• Aside Revisited
• You can still use div
• The hgroup element
• The dl element
• Semantic navigation with the nav element

Share and Save:

Understanding aside originally appeared on HTML5 Doctor on June 19, 2009.

]]> http://html5doctor.com/understanding-aside/feed/ 57