Aside Revisited

by .

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.

95 Responses on the article “Aside Revisited”

bruce says

Bum.

Better go and update my blog then….

James Tryon says

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

Peter Gasston says

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

Sidebar says

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?

Kyle Fox says

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?

kimblim says

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…

Rachel Nabors says

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

Oli says

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.

Gerrit van aaken says

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.

Mike Robinson says

@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).

Oli says

@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 :D Seems like the dust is starting to settle though

links for 2009-10-29 | Yostivanich says

[...] Aside Revis­ited | HTML5 Doctor “Aside is now accept­able to use for sec­ondary con­tent, such as a blogroll, groups of addi­tional nav­i­ga­tion and even adver­tis­ing if that con­tent is related to the page. When used within an arti­cle ele­ment, the con­tents should be specif­i­cally related to that arti­cle, for exam­ple a glos­sary. When using aside, please be aware of these changes of context.” (tags: html html5 w3c) [...]

Kyle Fox says

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

Dan Gayle says

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.

Dan Gayle says

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.

thinsoldier says

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.

thinsoldier says

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

Richard Clark says

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

Dan Gayle says

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.

Alohci says

@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”.

bruce says

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

Zygmuś says

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.

Mike Robinson says

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

TomkOx says

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

Keri says

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.

Seth says

(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”.

Richard Clark says

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.

Corey Mwamba says

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

bruce says

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.

Oli says

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

Corey Mwamba says

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?

bruce says

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.

Alohci says

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.

whatdoesitwant says

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

@Oli That’s the best description of aside that i’ve heard sofar. Cheers.

The article suggests something else:

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

I disagree with this somewhat limiting idea of aside’s application as a best practice. I argue that the unique behaviour of aside within html is that it allows a semantic relation to a sibling element, in the way that header tags and paragraph tags can have a semantic relation. Aside should therefore always be approached as sibling to (implying a parent) instead of as child of.

I understand the reflex to opt for nesting to explain the relation. It’s what I’ve become used to after years of xslt and xhtml hacking. But the suggested child of approach is a limited view that seems to be rooted in prior practices only. I’d gladly trade that approach for improved semantics. We use sibling definitions in css and jquery. I don’t see why the practice should not be extended to html5 as intended.

A sibling definition implies a parent.
When an aside is presented as a sibling to an article, it implies a section or a body as a container of both elements.
When an aside has an article as a container, it implies sibling content.
This sibling content can be all other content within the article container. The difference between this presentation of aside and the one as a sibling to the article is extremely subtle.
This sibling content can be presented as a bunch of paragraphs headed by a header tag. To make this relation more explicit, the aside, the bunch of paragraphs and the header could be thrown into a section. But I think that most times semantics of the relation can be deduced from content and positioning, making clear that the aside is related to that bunch of content and not to the entire article. (Loving the subtlety.)

I conclude that the nested approach is perfectly viable but that it does not exclude the definition of an aside as a sibling to the article (joined together in a section or body) and still being in relation. I would rather suggest that aside as a sibling is the preferable approach.

In my opinion the difference between an outside and inside (nested) aside should not be the indicator of what the aside relates to. That aproach limits layout freedom. Instead I encourage everyone to always think of aside as a sibling definition and view the relation semantically.
Practically, can you imagine the extra css hassle involved to visually present the nested aside apart from the article?

Illustrations:
http://www.flickr.com/photos/whatdoesitwant/4345832479/
http://www.flickr.com/photos/whatdoesitwant/4345832529/

Now with regard to the sidebar nonsense: throw all that stuff in a seperate section and see the sibling relations within that section. If you do not use sections for that but need an aside to hold your sidebar, put the article and its aside in a section instead. Develop your own house style (and templates) and stick to it.

whatdoesitwant says

Going through the post september spec again I see that my view has been dumped in favour of what is described in the article. Although I will work to comply with standard procedures, I still think that the sibling approach is better. To me this particular part of the spec change feels as if Palin has won from Obama.

Rhyaniwyn says

Meanwhile I continue to think that a blog sidebar containing…

- A picture and short bio of the author.
- Most recent tweet.
- A navigation list of recent posts.
- An advertisement.
- And a blogroll.

…would “overload” aside. Though maybe not if aside can contain section. Since all of those but the ad (tho I could make an argument if it’s targeted advertising) is tangentially related… I guess I should check on that.

Mark Kenyon says

Do you think it is reasonable to use an <aside> for a general ‘Introduction’ on a page that then moves on to more specific ‘articles’?

This page covers general stuff about books

Stuff about book 1

Stuff about book 2

Or would a seperate <section> tab be more appropriate?

Mark Kenyon says

Do you think it is reasonable to use an for a general ‘Introduction’ on a page that then moves on to more specific ‘articles’? Sorry the code would be:

<aside class=”intro”>
This page covers general stuff about books
</aside>
<article class=”bookArticle2 id=”book1″>
Stuff about book 1
</article>
<article class=”bookArticle2 id=”book2″>
Stuff about book 2
</article>
Or would a seperate <section> element be more appropriate?

Sean Fraser says

Does HTML 5 Doctor have an example of the proper (or, suggested) use of <aside> + a heading element in an HTML 5 document that will render an acceptable outline? Or, is there one (1) complete outline with all HTML 5 elements semantically used?

Danyal says

The original definition of aside was more appropriate. It was clearly HTML’s analogue of somebody pausing and saying, “as an aside…”.

Using aside to define a blog-roll, or something else that is not really an aside – that doesn’t seem quite right. Websites do not have asides. Stories, articles and anecdotes do.

HTML5 Live: A Sitepoint Course // Authentic Style Blog says

[...] <aside> – typically used to mark up sidebar content, but can also be used on other content – perhaps some text which is an ‘aside’ to the main content. Context plays an important part with this one and you can read more about that on the HTML5 Doctor site. [...]

Felixius says

As HTML5 picks up momentum in the wild and browsers make their attempted interpretations of the HTML5 specification (a work in progress), I am noticing myself having terrible problems working out whether or not to use many of these new tags. While many are really to address the categorising of actual content (for news feeds etc…), I, and the few web designers I know do not see it that way.

Aside from my brain exploding due to these issues (because that is a digression), I am still torn between using div-sidebar, and aside as a ‘styling’ tag. I mean, yes I can and do make the call, in the end… but who is to say that my interpretation of it is correct? Who is the boss of the code?

Having said that, the previous version of aside, was sidebar. Sidebar seems like a pretty obvious attempt at aiding the styling of a document.

Since “Document Design” goes hand in hand with “Document Layout” (in all my jobs anyway), SHOULD we be using the DIV tag just as much as we were?

To put it another way, AAAARRRRGGHHHH!

It is March 2011 and I am going to use ASIDE for my current project today… tomorrow, I might decide the opposite.

^_^

jeremias says

@Felixius I totally understand your frustration, I am also running into a wall when it comes to trying to use these practically versus following the spec.

I am very much looking forward to clarification on the value of HTML5 outlining because it seems to be very inconsistent.

For example, the WhatWg site has an example of using the element for a pullquote (using the element). However, because this example has no Heading it is returned as “Untitled Aside” in an HTML5 outliner.

In other words, because is sectioning content it requires a Heading if you want it to be labeled in the outline. It is the same issue I run into with the element which is also sectioning content. Looking forward to the resolution of all these nagging issues!

Oli Studholme says

@Felixius — with the new semantic elements there sometimes isn’t such a clear-cut distinction, due to differences in the perceived semantics. However for a page sidebar it’s pretty cut & dried — use the <aside> element. While a “sidebar” element might seem more logical, even for visual layout an aside might sometimes go e.g. underneath. When in doubt use our handy-dandy HTML5 element flowchart and our glossary definition to see you right.

You can still use <div>, but we find we don’t so much when using HTML5 and CSS3.

@jeremias —

because as sectioning content it requires a Heading if you want it to be labeled in the outline

While this is true, there’s no requirement for <aside> and <nav> to have headings. If the “untitled aside” bothers you, add the relevant heading and hide it using e.g. the margin-left: -9999em; technique, as you would for accessibility-related headings in HTML 4.

@everyone — while the new semantic elements might not exactly match the equivalent class names you used in HTML 4, this is generally to make them more flexible and useful. Give them a chance and see how you go! :)

Jacob says

Why does the example have so many h1 tags? I thought that was invalid markup.

bruce says

It’s always been permissible to have multiple H1s. HTML5 has an algorithm that cam work out an outline based upon the nesting inside section/ article/ nav/ aside of the heading elements.

xaguilars says

The aside element could also be the image gallery of an article or section

researching HTML5 « ART342~S11 says

[...] <aside> … An easy way to think about this is <aside> is related content that could be cut, eg by a mobile browser.    http://html5doctor.com/aside-revisited/ [...]

Doug says

I truly love html5 but at the same time <div id="sidebar">…</div> was a no brainer for anyone to understand.

The fact that there are several sites discussing the meaning of “aside” and its usage, while not actually hacking on a given website because we are busy commenting… yeah, kind of fail. I vote for a “sidebar” tag. Just sayin’.

DC

Oli Studholme says

@Doug — from the article’s conclusion:

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.

Doug says

@Dr. Oli Studholme

Yup, I get it. Just trying to point out that there seems to be too much confusion regarding understanding when it comes to “aside”, as perhaps you agree as well.

Oli Studholme says

@Doug — on the confusion-omoter, <aside> isn’t really that high (ref: <hgroup> ;) ). For whatever reason it always made sense to me. New stuff always takes a while to internalise, and <aside> will be no different. For anyone confused by <aside>, using <div id="sidebar">…</div> is still perfectly cromulent.

Doug says

@Dr. Oli Studholme

Yes, good point and thank you.

Another point to confirm:

Would everyone agree that its safe to say the content in <aside> should be, if you’ve done your job right, dynamic? So in other words, as its not uncommon for us web geeks to do good work but for the business unit to make a blunder of it later by doing things/changing things they shouldn’t be… for the case of <aside> if used correctly that would likely not happen… right?

Thanks,

DC

Oli Studholme says

@Doug — I’m not sure I understand. Are you referring to a page-level <aside> (cf. marginalia, literary asides, additional content etc)?

Anytime kittehs are let loose in your code I’d say all bets are off ;)

Doug says

Hehe yeah, kittens. Meow :P

Andi Smith says

If I wanted to use <aside> for an aside to my form fields, would that be allowed?

E.g. if I had an input, which already has a label as a short definition but I wanted to add additional information.

Andi

Alohci says

@Andi – probably not. The spec says:

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.

(my emphasis)

It’s unlikely that the additional information in that context could be considered separate from the form field.

In addition, <aside> is a sectioning element, so it ought to have a natural header for use in the document outline. That too is unlikely to be the case for your situation.

The best approach it probably to just add a second <label> element pointing to the same form field.

Johan says

thanks for the post! i agree with the other guys that said there should be a tag sidebar tag and while we’re at it drop the ul li tags inside the UL and create nav item “ni” tags.

Oli Studholme says

@Johan — how would dropping <ul><li> and using <ni> help you? are nav items something other than an unordered list?

Johan says

well – i guess it will be more semantic… before the nav tag (html5) i never wrapped my main navigation in a div. i added my nav id to the ul tag: <ul id="nav">. sometimes it feels as if HTML5 makes things a bit bloated and not as streamline/light as it says it is. i also think that people don’t realize that all tags are also containers. for example: why have a wrapper div – just give the body tag a width and margin auto to wrap your site and align it centre.

Mike says

There seems to be lots of discussion on when to use the “aside” tag, but no indication as to “why” to use it.

In other words, if I use it to whose advantage is it?

1) To a page coders advantage, so that they can more easily tell which content is only generally related?

OR

2) To a search engine so that it can rule out various page content?

Since there is no visual difference, I may as well just use “section”.

Where is the advantage to me as a coder?

Leprechaun says

I beg you pardon, but I must admit I find it astounding to read such refined semantical disquisitions from someone who doesn’t know the difference between “it’s” and “its”.
Have you ever thought about going humbly back to basic English grammar? Believe me or not, that would give more “thickness” to your writings, much more than being part of the hippest web communities.
I mean this from the heart.

Oli Studholme says

@Johan — This way you can also include a navigation title and other content, and lists are already fully supported and understood.

@Mike — I don’t think search engines will treat <aside> differently. I personally find it useful to have an element for this purpose. It’s also possible to do more stuff if your code is more semantic, with styling being only a basic example.

Of course there’s nothing to stop you using <section>, or <div>.

@Leprechaun — While I personally agree, it is somewhat gauche to say so, and adds nothing to the discussion on <aside>.

Also, “I beg you pardon”? “thickness”?? ppl in glasshouses… ;)

anon says

This is why people are not going to use this spec because it is going to change and change and change.
How am I supposed to convince clients to recode their website to change according to this spec above.

Personally, I do not think you guys have it together and you cannot predicate the outcome.

You are creating a messy spec and should keep it simple.

Edward says

I am still lost. What should I use for a collection of items on a site’s homepage. Let’s say I have (a) an item listing recent blog posts, (b) a featured article item, (c) a recent tutorial item, (d) a recent photos gallery, etc.

Each of these can be seen as independent (thus suggesting the use of the article tag) but since there is no primary purpose of the page other than displaying these assorted items – aside seems appropriate. My problem is that the definitions for <article>, <section>, and <aside> appear to overlap:

- tangentially related to the content surrounding it (aside)
- secondary content related to the site as a whole (aside)
- component of a page (article)
- a self-contained composition (article)
- independently distributable or reusable (article)
- independent item of content (article)
- stuff that isn’t the above? (section)

Something can be tangentially related and independent and many other things all at once

Aleksi says

tangentially related to the content surrounding it
secondary content related to the site as a whole

Could aside be used for example, to group information about the author of the page + contact information?

Thanks

Bjarni Wark says

Thanks for the additional clarification on how to use :

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 is appropriate. Of course, if your “sidebar” is purely navigation that is key to the page, something like would be more appropriate.

Twenty200 says

Part of the problem of figuring out what does and doesn’t qualify as a proper use of an aside is that WordPress has taken over the term. Maybe other CMSes have too.

Within WordPress, an aside is a blog entry without a title, though it takes them a ridiculous amount of codex notes to explain that. Instead, they use examples such as whispering a note to a friend.

…?

But WordPress also assigns all sorts of other content as asides. All widgets, for example, are often asides. And since most themes are so complex that the owner of the website uses hacks and plugins rather than editing the code, even more content gets labelled as asides.

At this point, regardless of what asides were intended to be, they have become nothing more than another name for a div. Aside tells you absolutely nothing about what the content within it might be. Much of what WordPress codes as asides have nothing to do with the current page entry.

Maybe you’re thinking “But that’s not how it’s supposed to be!” to which I reply “Hi! Welcome to planet Earth. I hope you enjoy your stay.”

So long as CMS themes exist (especially when the person using the theme did not code it), html will need a sidebar element (or, perhaps name it something else, like widget or extras). Without that, CMSes like WordPress will bastardize whatever element comes closest, and that element (currently, aside) will be meaningless.

[...] for the article. How can it know this? Well, the specification mandates that asides are for tangentially related content, not important stuff that way found in the main body of the article. Also, the parser’s [...]

Trung Hieu Le says

Hum, I’ve used the “aside” elements outside the “article” element for a time before reading this article. Thank the spec writer for allow me continue using this without having to rewrite my HTML layout.

Joe says

Currently designing my wp site and man.. I need to update myself with HTML5.. Its time to move on and bye to html4… Thanks Mike!

-Joe

Henry says

How would you style two aside tags?

Probably a simple question but Im kinda new thanks

John says

Is the text search engine readable or become hidden?

Mike Robinson says

@Henry: You can style them as you would any thing else.

@John: While I don’t know the inner workings of the various search engines or how they will rank an aside’s content, I will say that the text is still readable by the search engine. What it does with that content is up to its algorithm.

Roy says

May I suggest adding the very clarifying flow chart to the article proper? http://html5doctor.com/flowchart Understanding when to use article is a very relative-to-other-elements process, and the flow chart greatly clarifies.

John says

Am I right to assume that an aside that is used as a sidebar should have role=’complementary’ while an aside inside an article should have role=’note’ ?

Also, I am still somewhat confused as to how to mark up individual “widgets” in a sidebar. Most of them would be things like a tagcloud or category-links (is that considered main navigation? so should we use a nav or a section?)
Something like a featured article of featured item should probably go into a section (since it has a heading) right?
But how about advertisements? They typically have nothing to do with the page-outline (content-wise) nor do they have a heading?
At first I thought I should probably use a div for this, but perhaps figure could also be used for this? (since an ad could make sense on it’s own)? Or am I over-thinking this?

    Bruce Lawson says

    I’d mark up tag clouds and category links as <nav> as that’s what they are. I’d make a featured article and <article> (that’s what it is, right!).

    An advert, not related to page content is an <aside> in my opinion.

    I just used complementary roles for <aside>.

John says

I had to think about this.
1) I agree with the nav for tag-clouds and categroies, it would make the most sense. Thank you.
2) The featured article might be an article, but I would not want to have it show up in any syndication of the page. So wouldn’t a section be better?
3) If we assume an article is not related to content (or at best is targeted at the content) then would we want it to show up in the outline? If yes then i agree with an aside, if no, then we have a problem since there is no way, that I know of, to remove an item from an outline. At best I would not let it have it’s own heading, implied or explicit so I am leaning towards a DIV. Unless I am mistaken?
4) Also, WAI AIRA makes a distinction between complementary and note roles. Where complementary is a landmark and note is not. Hence I would think that sidebars would be complementary and pull-quotes and such would be notes?

John says

Errata: at point 3) it should read: If we assume an ADVERT [...]

Roy says

@john Check out the flow chart that html5doctor made: http://html5doctor.com/downloads/h5d-sectioning-flowchart.pdf

I think that format makes the HTML 5 stuff much easier to parse against each other, though it doesn’t go into nitty gritty details.

As far as article syndication, don’t forget that things that would work as a unit able to have “share on Facebook” or “share to pinterest” next to them is another good way to think of what qualifies as an block. alternatively, maybe it’s a news feed on your own site that the article block would be shareable to.

Finally, you say you don’t literally want to share/syndicate a block yourself. Then the thing to consider is whether you’re willing to allow bots like googlebot to share stuff inside article as a block. If so, you could probably still use article. If not, that’s a good reason to avoid article, and putting the content explicitly outside any article, aside, and section elements in a plain div may make sense. It still may end up in an outline that way though, depends on what is doing the outlining.

In the end

Roy says

Ah, should have used code tags here, apparently, ah well, the gist of it is intact.

In the end, a scraper can probably get to anything (not brought in by javascript probably being an exception), so you can only leave signposts, not commands.

John says

@Roy: Thanks for the input. If I understand correctly (assuming an ideal world where scrapers and UAs adhere to specs) the seelction of div vs section vs article would be something like this:

1) Does it belong in the outline (have a heading and be announced to AT) if not use a DIV
2) Does it get shared or is it allowed to be shared outside the document where it is published? If yes use an ARTICLE
3) in all other cases use a SECTION.

If this is correct then I would assume things like “last person to register”, “picture of the week” etc. would belong mostly in a section, while things like “latest news”, “featured article” etc. would best be placed in an article. (again, assuming an ideal world)

macro says

I digged web for the correct use of aside. even looking inside the source code of many HTML5 websites. but there was not a standard used methode.

but you presented the best definition ever . thanks

Adamantium says

I’d just like to say that I also find aside totally confusing. All explanations so far in this page and in the HTML5 Sitepoint book on the subject are all contradictory and confusing. I won’t be using aside until everyone can agree what it’s actually supposed to be good for.

I totally agree with Dan Gayle (October 29, 2009 at 6:25 pm) about profiling sites, finding a bunch of elements that are used regularly, then changing them to confuse everyone who ever built a website. Then creating a thing called aside which sound suspiciously like sidebar but actually that’s not allowed to be used for a sidebar. Where do they get these people? Smart people do the stupidest things when it comes to usability… every.. single… time… It gets very very old.

Andreas Rejbrand says

@Adamantium: I don’t understand why people find this element hard to use. A typical usage of this element would be in my article on Swedish grammar. <aside> would be an ideal replacement for the DIVs titled “På tal om det…”. In these boxes, I make interesting notes about typography, digital word processing, and grammar, that are somewhat related to the main topic at the same place in the document, but not really part of the main text. They are more like “bonus comments”.

More examples are given in the spec. When uncertain about the semantics of an HTML element, you should not (sorry!) go to HTML5doctor or any book, but the official specification at W3C (or WHATWG).

This text, in its current form, cannot be misunderstood, I think.

Jeff Day says

To me, the crux of the issue with using <aside> properly is relating to something Oli said above, “An easy way to think about this is <aside> is related content that could be cut, eg by a mobile browser.”

I would then imagine all “asides” are things that could potentially be omitted, while still maintaining a sensible page. For example, an article about web browsers, that has a tangentially related survey/chart showing the current market share of web browsers. If the article itself does not depend on that chart, then the chart could be considered an “aside.”

However, a navigation bar is an integral part of the page. Using an aside for a navigation bar (even if the aside contains a nav element) is implying that you could cut the nav bar from the site and not affect the meaning of the site. If the nav is only “related articles” then maybe that’s ok, but if it is necessary site navigation, then an aside would be inappropriate.

Does this distinction hold, or am I wrong here?

Join the discussion.

Some HTML is ok

You can use these tags:
<a href="" title="">
<abbr title="">
<b>
<blockquote cite="">
<cite>
<del datetime="">
<em>
<i>
<q cite="">
<strong>

You can also use <code>, and remember to use &lt; and &gt; for brackets.