Willem on flickr
Aside (3) On the rendering of 'nested' asides
Now, when defining a nested, floated aside between sibling content elements all rendering is restored as expected.
----------------------
The text in these examples is nonsensical filling, random bits from different sources. For the sake of my argument, please regard the darker areas as semantic asides to the lighter areas. I'll try to put all this in blog post with better examples.
-----------------------
On another matter, it's been suggested at html5doctor.com/aside-revisited/ that "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 darker area in this version would be correct according to this definition. I, for one, completely 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. I understand the reflex of developers and designers to opt for nesting to explain the relation but this is a limited view that is simply a result of prior practices that i'd gladly trade for better semantics. We do this in css, jquery. I don't see why the practice shouldn't be extended to html5 as was intended.
Oli gives us a better definition:
"An easy way to think about this is is related content that could be cut, eg by a mobile browser."
Also, practicly, can you imagine the extra hassle involved to present the nested element apart from the article?
Now, the use of aside in this example is fine. I could suppose that it sets related content against the surrounding paragraphs preheaded by "Requirements".
The proper interpretation could be deduced from positioning: If the aside runs along surrounding blocks that are headed by a header tag, it would have to be interpreted as being in relation to thàt group.
With no headers available for grouping it would have to be interpreted as an aside to the entire article's còntent.
[continued in Asides (4) On the rendering of asides]
Aside (3) On the rendering of 'nested' asides
Now, when defining a nested, floated aside between sibling content elements all rendering is restored as expected.
----------------------
The text in these examples is nonsensical filling, random bits from different sources. For the sake of my argument, please regard the darker areas as semantic asides to the lighter areas. I'll try to put all this in blog post with better examples.
-----------------------
On another matter, it's been suggested at html5doctor.com/aside-revisited/ that "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 darker area in this version would be correct according to this definition. I, for one, completely 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. I understand the reflex of developers and designers to opt for nesting to explain the relation but this is a limited view that is simply a result of prior practices that i'd gladly trade for better semantics. We do this in css, jquery. I don't see why the practice shouldn't be extended to html5 as was intended.
Oli gives us a better definition:
"An easy way to think about this is is related content that could be cut, eg by a mobile browser."
Also, practicly, can you imagine the extra hassle involved to present the nested element apart from the article?
Now, the use of aside in this example is fine. I could suppose that it sets related content against the surrounding paragraphs preheaded by "Requirements".
The proper interpretation could be deduced from positioning: If the aside runs along surrounding blocks that are headed by a header tag, it would have to be interpreted as being in relation to thàt group.
With no headers available for grouping it would have to be interpreted as an aside to the entire article's còntent.
[continued in Asides (4) On the rendering of asides]