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.
98 Responses on the article “Aside Revisited”
[…] 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 […]
Bum.
Better go and update my blog then….
That’s hot. How long tell we can start using this?
What a timely article; I was just debating this very issue. Thanks for the clarification!
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?
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?
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…
How contextual! But I wonder if something like a “sidebar” tag would be more appropriate and reduce confusion?
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.
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.
@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).@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
[…] 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) […]
@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.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.
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.
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.
Continuing thought:
Seriously, this site needs more screenshots/visual aids of real-world examples. None of that bare-bones grey-box example junk.
@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.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.
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
@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”.
@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.
[…] HTML5 people say that the new <aside> element is named such because <sidebar> is […]
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.
@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.
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>.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.
(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”.
Seth, there isn’t a
sidebarelement, do you meanaside? You can always asectionelement within anasidemuch like we do on this site.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?????]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.
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 ;-)
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?
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.
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.
@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.
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.
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.
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?
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?
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?[…] http://html5doctor.com/aside-revisited/ […]
[…] Liens vers l’article Aside revisité en anglais Partagez : […]
[…] — HTML 4 and XHTML 1 to HTML 5 (@boblet)HTML5 Doctor’s articles on header, section, aside, nav, footer@boblet’s articles on div, section, and article; nav, aside, figure, and footer; […]
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.
[…] <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. […]
[…] it wasn’t to be used for that. But it seems that the developers didn’t accept this and now the spec has been updated to make the aside tag more useful for a web designer. Now, who knows what other tags might change […]
[…] This article over at HTML5 Doctor was my main reference when laying out the <aside> tag. […]
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.
^_^
@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
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!
@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 —
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. themargin-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! :)
Why does the example have so many h1 tags? I thought that was invalid markup.
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.
The aside element could also be the image gallery of an article or section
[…] <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/ […]
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
@Doug — from the article’s conclusion:
@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.
@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.@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
@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 ;)
Hehe yeah, kittens. Meow :P
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
@Andi – probably not. The spec says:
(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.
[…] med en klasse eller id, så har HTML5 tags med semantisk betydning, eksempelvis article, aside og nav. I tillegg har en rekke tags blitt redefinert, for eksempel […]
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.
@Johan — how would dropping
<ul><li>and using<ni>help you? are nav items something other than an unordered list?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.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?
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.
@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… ;)
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.
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
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
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.
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 […]
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.
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
How would you style two aside tags?
Probably a simple question but Im kinda new thanks
Is the text search engine readable or become hidden?
@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.
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.
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?
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>.
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?
Errata: at point 3) it should read: If we assume an ADVERT […]
@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
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.
@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)
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
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.
@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.
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?
I ONLY use aside for the comments section of WordPress. I did use it for article secondary content but I was just as confused by the name as most so I stuck with one usage.
I never use it for a sidebar (but I guess I could now….). A sidebar is more ‘nav’ or ‘section’ than it is ‘aside’, for me.
My thought is that comments within WordPress are definitively essential secondary information essential to article post (content).
In all, I wonder if the HTML5 developers thought about the wording fully and never expected anyone to use it for “sidebar” as in “aside from the original content” as apposed to “aside the article content?” Semantics at its most confusing best.
With regarding to marking up advertisement, I find such contents are not important enough to be treated as landmarks so
asideisn’t the right element to use.Hi, can I use this option for the page with the category?
Is it worth it to enter tags subscription form and the buttons of social networks in esayd tag?
Is it possible to conclude the latest articles in this category section tag and tag him inside article?
– header
– main
– article
– header // header article
– div // text article
– p
– p
– aside // tags
– tags
– aside //subscribe and share buttons
– subscribe
– share
– section // latests posts
– article
– article
– article
– aside
– section // polls
– nav // category
– section // search
– footer
Join the discussion.