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.
41 Responses to “ Aside Revisited ”
Comment by Tweets that mention Aside Revisited | HTML5 Doctor -- Topsy.com at
[...] 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
Bum.
Better go and update my blog then….
Comment by James Tryon at
That’s hot. How long tell we can start using this?
Comment by Peter Gasston at
What a timely article; I was just debating this very issue. Thanks for the clarification!
Comment by Sidebar at
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
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
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
How contextual! But I wonder if something like a “sidebar” tag would be more appropriate and reduce confusion?
Comment by Oli at
That’s a change? I thought that’s how
<aside>always worked (?)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:
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
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
@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:@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
@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
[...] 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
@oli @mike — I wasn’t suggesting a
sidebarelement. 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
sectionelement 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
asidewould be a more appropriate element to use for#aux_content.My question, then, is how one would choose between
sectionorasidewhen constructing this sort of markup, especially when considering that auxiliary content typically contains multiple pieces of content.Comment by Dan Gayle at
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
And I thought that this might be appropriate:
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
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
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
@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
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
headerandfooter. I’ll try and find the link for you.Comment by Dan Gayle at
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:
Semantics indeed.
Comment by bruce at
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
@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
[...] Aside Revisited | HTML5 Doctor – [...]
Comment by bruce at
@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
[...] HTML5 people say that the new <aside> element is named such because <sidebar> is [...]
Comment by Zygmuś at
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
[...] Aside Revisited [...]
Comment by Mike Robinson at
@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
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
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
(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
Seth, there isn’t a
sidebarelement, do you meanaside? You can always asectionelement within anasidemuch like we do on this site.Comment by Corey Mwamba at
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
asidewould 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
navelement with appropriate CSS to shift it to the side? Then we could use asides as footnotes and annotations [although that may be covered bycomment?????]Comment by bruce at
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
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
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
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
Indeed. I note that towards the end he says:
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
I’ll try that again:
Indeed. I note that towards the end he says:
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 whatdoesitwant at
@Oli That’s the best description of aside that i’ve heard sofar. Cheers.
The article suggests something else:
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.
Comment by whatdoesitwant at
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.