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.

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.

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

Indeed. I note that towards the end he says:

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

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

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.

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