Aside Revisited

This is an update to a previous article. The spec has changed to allow aside to be used for secondary content, changing its context depending on whether it's contained within an article.

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.

Possibly Related Posts:

Share and Save:

No Responses to “ Aside Revisited ”

Comment by Tweets that mention Aside Revisited | HTML5 Doctor -- Topsy.com at October 28th, 2009 at 2:36 pm

[...] This post was mentioned on Twitter by Chris Coyier, Jack Franklin. Jack Franklin said: RT @jackosborne: The @html5doctor has published a new post about the aside element as it has now changed http://bit.ly/2XMixM [...]

Comment by bruce at October 28th, 2009 at 4:11 pm

Bum.

Better go and update my blog then….

Comment by James Tryon at October 28th, 2009 at 4:33 pm

That’s hot. How long tell we can start using this?

Comment by Peter Gasston at October 28th, 2009 at 4:34 pm

What a timely article; I was just debating this very issue. Thanks for the clarification!

Comment by Sidebar at October 28th, 2009 at 5:03 pm

So everybody uses aside as a sidebar div and they’re all wrong.

Hmm, how about creating then a “SIDEBAR” tag so we can use that instead?

Comment by Kyle Fox at October 28th, 2009 at 6:14 pm

For site-level stuff like blogrolls, advertisements, “about me”, etc., how do you choose between the <aside> or <section>?

For me it makes more sense to use <aside> tags exclusively inside an <article>, to give it proper context. I think it’s use-case is less clear now that it can also be used for secondary content.

What’s the purpose of adding all these new tags if they can be used all over the place interchangeably anyway?

Comment by kimblim at October 28th, 2009 at 8:52 pm

Nice to see an actual example of aside in use – now it kind of makes sense

Btw: You’ve got your definition list wrong – you’ve got a dd as the wrapper element instead of a dl…

Comment by Rachel Nabors at October 28th, 2009 at 8:59 pm

How contextual! But I wonder if something like a “sidebar” tag would be more appropriate and reduce confusion?

Comment by Oli at October 29th, 2009 at 6:20 am

That’s a change? I thought that’s how <aside> always worked (?)

<aside> content should be additional to (but not essential to the understanding of) the main content, ie any related content … keep in mind the <aside> must be related—having your sidebar in an <aside> in the page’s main <section> is fine, but site-wide information shouldn’t appear in an article’s <aside>, for example.

An easy way to think about this is <aside> is related content that could be cut, eg by a mobile browser.

@Sidebar—no, it is possible to use <aside> for a sidebar, as long as it’s information tangentially related to the <aside>’s container. Read the article again

@Mike—maybe it’d be good to change:

Please keep in mind that aside, and similarly secondary content, does not mean “sidebar”

to “Please keep in mind that aside, and similarly secondary content, does not necessarily mean ‘sidebar’”, to avoid @Sidebar’s confusion.

@Kyle and @Rachel—The new semantic elements (mostly sectioning ones) can seem a little fuzzy, but that’s because they represent semantics, rather than one clearly defined thing, like an image or a list. Having an element for each specific context or use-case (rather than these more general-use ones) would definitely be a bad idea. While it takes making some HTML5 sites to get your head around, think Russian Dolls and you’ll have a head start.

Comment by Gerrit van aaken at October 29th, 2009 at 8:03 am

Now the question seems to be whether we should use more than one site-related “aside” element (one for each block in the sidebar, as a replacement for “div.sidebox”), or if aside can be used instead of a “sidebar” element.

Comment by Mike Robinson at October 29th, 2009 at 10:52 am

@Sidebar: “Sidebar” relates to the presentation of an element, rather than it’s content. Separation of content and presentation is vital, but to clarify: what you refer to as a “sidebar” is likely to be “secondary content”, and therefore <aside> is appropriate. Of course, if your “sidebar” is purely navigation that is key to the page, something like <nav> would be more appropriate. Presentation is irrelevant at the mark-up stage, so please refer to the content itself (“Primary Content”, “Secondary Content”, “Navigation”, etc) rather than how it could be styled.

@Kyle, Rachel, Gerrit & Sidebar: <aside> was originally called “sidebar” but was changed due to the presentational connotations with that name. How <aside> changes context depending on it’s parent elements is perfectly logical and is not the only new element that does so. For example, <header> and <footer> can exist directly in the <body>, in an <article>, or even in a <section>. The <header> of an <article> adopts a context that is dependant on that <article>, rather than the HTML document as a whole. Just like we don’t have a “subnav” element to differ from <nav>, adding an additional “sidebar” elment would be redundant.

@kimblim: Doh! Thanks for that, I’ve corrected the example

@Oli: Thanks for your great response! I’ve made that change, bit silly of me to miss it in the first place. In regards to how it used to be defined, there was nothing in the spec (particularly no examples) that deemed <aside> suitable for secondary content. Only recently was the third example of <aside>’s use added, along with this line:

The element can be used for typographical effects like pull quotes or sidebars, for advertising, for groups of nav elements, and for other content that is considered separate from the main content of the page.

@Gerrit: It is acceptable to use multiple <aside> elements, particularly if you are grouping it’s contents by a particular theme. For example, an “Elsewhere” group of content that acts as a lifestream, plus a group of content directly related to the site (“Recent Posts”, “Tag Cloud”, etc).

Comment by Oli at October 29th, 2009 at 2:06 pm

@Mike—Hrm, I’m now wondering if I read more into it than everyone else, or got some inside info on IRC. No matter! Hurrah for a more explicit spec eh

While I personally love the nuance the new semantic elements bring, they certainly seem to be easy to misinterpret huh Seems like the dust is starting to settle though

Comment by links for 2009-10-29 | Yostivanich at October 29th, 2009 at 2:09 pm

[...] Aside Revisited | HTML5 Doctor “Aside is now acceptable to use for secondary content, such as a blogroll, groups of additional navigation and even advertising if that content is related to the page. When used within an article element, the contents should be specifically related to that article, for example a glossary. When using aside, please be aware of these changes of context.” (tags: html html5 w3c) [...]

Comment by Kyle Fox at October 29th, 2009 at 3:14 pm

@oli @mike — I wasn’t suggesting a sidebar element. I realize that context is inferred by an element’s location in the DOM (i.e., the parent node gives a node it’s own context). Nor was I suggesting that there be an element for “each specific context or use-case”.

The point I’m trying to raise is that previously it was suggested to use a section element to identify auxiliary/secondary site-level content, perhaps like:

<section id="main_content"><article>...</article>...</section>
<section id="aux_content"></section>

whereas now it seems like and aside would be a more appropriate element to use for #aux_content.

My question, then, is how one would choose between section or aside when constructing this sort of markup, especially when considering that auxiliary content typically contains multiple pieces of content.

Comment by Dan Gayle at October 29th, 2009 at 3:43 pm

This whole thing about “is it or is it not navigation/is it or is it not secondary content to the article” stuff is more confusing than ever. When does a website EVER have a “sidebar” without it having some kind of navigation? I completely understand the different use cases, and the idea seems close to what I do anyway.

For instance, I typically have a <div class="sidebar"> element that holds things navigational elements, ads, and other site-wide informational elements.

Within my <div class="content"> block, I sometimes have what I refer to as an “inline sidebar”, <div class="inline-sidebar">. This inline sidebar does indeed work specifically in the manner in which you describe how the <aside> element should work.

If constrained to that use, it would make a lot more sense, particularly when it comes to parsing, such as your mobile device example. What happens when we web designers, confused by the switching context of these stupid elements, decide to make our <div class="sidebar"> elements into <aside> elements, and the user agents of our mobile devices parse that out, as you suggest?

The whole “semantics” thing is getting way out of hand sometimes. If you do a survey and everyone calls the same element “sidebar”, and you decide to create an element to take up its role, but “oh by the way, it doesn’t do what you think it does and we’re going to call it something else” is a stupid, stupid mistake.

Comment by Dan Gayle at October 29th, 2009 at 3:50 pm

And I thought that this might be appropriate:

side·bar (-bär′)noun1. a short article dealing with a sidelight of a major news story and printed alongside it2. a discussion at the bench between the lawyers and the judge, conducted outside the hearing of the juryYourDictionary.com/sidebar

I come from a newspaper background, and I have always thought of a sidebar in this manner. It has nothing to do with the presentation.

Comment by thinsoldier at October 29th, 2009 at 4:56 pm

Idea for future article:
Take a screenshot of a real site (I can supply one
Discuss the original html4 tags & id/classes used.
Then you guys label the screenshot with what html5 tags & id/class values would be best and why.

Comment by thinsoldier at October 29th, 2009 at 5:07 pm

Continuing thought:
Seriously, this site needs more screenshots/visual aids of real-world examples. None of that bare-bones grey-box example junk.

Comment by Richard Clark at October 29th, 2009 at 6:18 pm

@thinsoldier good points, and glad to hear your thoughts, this is actually something we’ve got in the pipeline but we were thinking of guiding people through the process by writing the markup as well. We’ll try and add some more real world examples in the future. If you’ve any other thoughts be sure to let us know.

@dangayle

If you do a survey and everyone calls the same element “sidebar”, and you decide to create an element to take up its role, but “oh by the way, it doesn’t do what you think it does and we’re going to call it something else” is a stupid, stupid mistake.

Thats exactly what Hixie did (well not a survey but he profiled a tonne of sites for class and id names) and it’s why we’ve got elements like header and footer. I’ll try and find the link for you.

Comment by Dan Gayle at October 29th, 2009 at 6:25 pm

Thats exactly what Hixie did (well not a survey but he profiled a tonne of sites for class and id names) and it’s why we’ve got elements like header and footer. I’ll try and find the link for you.Richard Clark

That’s exactly my point. Why go 3/4 of the way and use nomenclature that web designers understand, then attempt to replace something they do understand with something that a) is named funny and b) doesn’t even work the same anyway?

You have now introduced confusion where confusion need not exist.

Try this on:

side·bar (-bär?)
noun
1. a short article dealing with a sidelight of a major news story and printed alongside it
2. a discussion at the bench between the lawyers and the judge, conducted outside the hearing of the jury
YourDictionary.com/sidebar

Semantics indeed.

Comment by bruce at October 29th, 2009 at 8:22 pm

Here’s the link that maps the most common class names in 1,000,000,000 pages to their html5 elements http://code.google.com/webstats/2005-12/classes.html

Comment by Alohci at October 30th, 2009 at 1:23 am

@bruce. Interesting list. Some comments:

1) The class names “main”, “body” and probably “content” don’t map exactly onto the “article” element’s semantics. In fact, article is explicitly disallowed from acting as “main” or “body”.

2) The “date” element seems to have disappeared in favour of the “time” element. The class name “time” is not listed.

3) None of the class names “section”, “article” and “aside” appear at all.

Neither do they appear in Rene Saarsoo’s survey (http://triin.net/2006/06/12/CSS#class-selectors) or John Allsopp list of classes (http://westciv.typepad.com/dog_or_higher/2005/11/real_world_sema.html Table 3).

Little wonder then, that there is so much confusion about how to use these elements correctly, since it seems that they are not achieving their original intent of “paving the cowpaths”.

Comment by Bookmarks for October 27th through October 30th « LostFocus at October 30th, 2009 at 7:01 am

[...] Aside Revisited | HTML5 Doctor – [...]

Comment by bruce at October 30th, 2009 at 11:48 am

@Alohci

1) true. But this research shows the origin of the idea of document landmarks becoming elements in their own right.

2) I should have said – this is from December 2005. Spec has changed quite a bit since then.

3) section is from xhtml2. article – as the main content of the page – is easily discernible as an attempt to make a generic element that encompasses main / content/ body. Aside seems (to me) to be an obvious addition to “landmark” elements. YMMV, of course.

Re Saarsoo/ Allsopp lists – pass. Maybe Hixie will stop by and answer.

Comment by A brief note on HTML5 Semantics | Daniel John Gayle at October 30th, 2009 at 3:19 pm

[...] HTML5 people say that the new <aside> element is named such because <sidebar> is [...]

Comment by Zygmuś at November 4th, 2009 at 12:19 pm

HTML 6 will have also tags: “undecided”, “internetexploreronly” and “waterclosed”. Sorry pseudo webmasters loved in “beautiful desgin build with XHTML 7 Nitro Edition + CSS 9″, but I am switching… back: to the HTML 3.2 Final. I can still use with it: CSS 1-3 and ECMA libraries/extensions like jQuery. HTML>4.01 Strict just does big suck. I will never support special html-fixations for iPhones etc. I do not care for guests/users working with this kind of device. It is not my problem, but their. In fact, Internet Explorer users will have always support, becouse you have to care for them. If you will not support them (even by making websites layouts based on tables) your site will means nothing to the whole wide world.

Comment by Collection of HTML5 Resources to Move You Forward at November 4th, 2009 at 2:40 pm

[...] Aside Revisited [...]

Comment by Mike Robinson at November 4th, 2009 at 3:32 pm

@Zygmuś: You clearly have a lot of issues with the way HTML is heading, but I am not sure how your comment relates to this particular article! It might be more worth your time to republish that on something more relevant.

Comment by TomkOx at November 4th, 2009 at 7:41 pm

Someone said (in prev-version of article) that for image should be used <figure> instead of <aside>. But it is not true! Reason: if image is “just an ad-on relative to the main content” it can be put into the <figure> and this “figure” can be inserted into <aside>.

Comment by Keri at November 13th, 2009 at 4:31 pm

As the definition of has changed the implementations in the leading edge browsers will need to change, and that will take time. I’m waiting until at least one browser announces support for the new definition before I do any more HTML5 testing.

Comment by Seth at December 19th, 2009 at 11:39 pm

(Sorry, again! I tried using an opening and closing <code> tag but must have done something wrong. I will try using lt and gt for < and >. A preview option would be nice to catch these things

I would suggest creating a module <mod> element for secondary blocks of modular content on a page. These modules of content can then be styled and placed using CSS (whether on the side, at the top, the bottom, etc.) and would be a better structural name than <sidebar>.

If this last post doesn’t work, I am try to suggest an element called “mod” instead of “sidebar”.

Comment by Richard Clark at December 21st, 2009 at 2:26 pm

Seth, there isn’t a sidebar element, do you mean aside? You can always a section element within an aside much like we do on this site.

Comment by Corey Mwamba at January 5th, 2010 at 7:57 am

I think the issue has always been in
1. the wording of the draft; and
2. what people actually understand by “sidebar in typography“

If the draft had used the word marginalia, then I think the definition of aside would have been clearer. "Sidebar" to most people designing for and using the web doesn't mean "marginalia" - it means a bar at the side of page where you put a menu. But that's semantics for you.

Would it not be more appropriate to recommend that if people want a sidebar, they use a nav element with appropriate CSS to shift it to the side? Then we could use asides as footnotes and annotations [although that may be covered by comment?????]

Comment by bruce at January 5th, 2010 at 6:19 pm

Thing is, corey, most sidebard are a bunch of different navs – eg, this site has “recent articles”, contributing authors, categories, each of which is its own nav, so aside acts as a container for them.

Comment by Oli at January 6th, 2010 at 8:57 am

If you only have a nav element in your page’s sidebar then you don’t need aside as a wrapper—just position the nav. However normally sidebars have a bunch of different content, and in this case putting all of it in an aside makes sense. You can also use aside for footnotes, sidenotes and whatever else you want through the glory of class and id

Comment by Corey Mwamba at January 6th, 2010 at 10:34 am

The thing is that none of the menus at the side of this site is really an aside. They’re all navs, and it doesn’t matter whether they relate to the main content of the page. So as Oli says, you could just position the nav and semantically stick them all in a generic div [or a overarching nav?]. Is that not right? Or will the browser treat the aside differently to a nav, making it more appropriate? Basically, is everybody agreeing with the semantics?

Comment by bruce at January 6th, 2010 at 4:09 pm

Corey. You can have navs inside a nav, I believe (I just looked at the spec as I never thought of doing that before). But most sidebars have things that aren’t nav *and* nav interspersed. On my personal blog, for example, I have various nav (archives, categories) plus recent comments (arguably, nav) and (definitely *not* nav) a random photo plus colophon (“powered by WordPress”).

So for this example, an over-arching nav wouldn’t be appropriate. An over-arching div would be (as that’s what we use in HTML4). But the spec defines aside as also being appropriate here.

An interesting read is Lachlan Hunt’s The History of <aside> for sidebars.

Comment by Alohci at January 6th, 2010 at 10:00 pm

An interesting read is Lachlan Hunt’s The History of for sidebars.

Indeed. I note that towards the end he says:

…it’s clear that the use case of a pullout-type aside is conceptually
different from that of a page sidebar, and for that reason, I think it
might be worth reintroducing the element as a distinct
sectioning element, and limiting the uses of to things like
pullouts, footnotes and other non-sidebar uses.

It’s quite rare for me to agree with Lachlan on a matter of opinion. In this case he is spot on. It would have spared so much confusion.

Comment by Alohci at January 6th, 2010 at 10:05 pm

I’ll try that again:

An interesting read is Lachlan Hunt’s The History of <aside> for sidebars.

Indeed. I note that towards the end he says:

…it’s clear that the use case of a pullout-type aside is conceptually
different from that of a page sidebar, and for that reason, I think it
might be worth reintroducing the <sidebar> element as a distinct
sectioning element, and limiting the uses of <aside> to things like
pullouts, footnotes and other non-sidebar uses.

It’s quite rare for me to agree with Lachlan on a matter of opinion. In this case he is spot on. It would have spared so much confusion.

HTML5 Doctor

helping you implement HTML5 today

Aside Revisited

Aside redefined

Examples of `aside` in two different contexts