However, I have strong and complex feelings on this, being interested in the semantic web since 2003 and remember ardently following xhtml1.0 strict standards.
main: great, good.
header/footer: awesome, thanks
nav: oh wow how did we live through xhtml without it?
article/section/aside: wow, trash, wtf?
Article, section and aside are so vague that they semantically mean about the same thing as div. You still have to drop identifying classes on them to actually note what they are intended to contain.
Comments/assorted widgets/supplementary info can be articles, but also can be sections, but can also be asides or contain or be contained by any mixture of the above. I'm not saying div is the gold standard, but this is one area whatwg kinda dropped the ball. Semantically, it doesn't say what it is any more than div does.
Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
That's a very interesting perspective, genuinely, and I'll have to think more about it.
But my initial reaction is that I think article and section at least have pretty clear meanings:
An <article> should be used only for a high-level portion of the document that is sufficiently independent that if it were plucked out of your page and dropped into another page, it would still make perfect sense, like a blog post or tweet.
A <section> is a block that doesn't meet the above independence criteria, because it only makes sense within the context of the surrounding content, but that you would list in your table of contents.
An <aside> is, admittedly, a bit more vague: is a "note" block in the middle of your text an "aside"? I often use phrases in my writing like "as an aside, ...", but I wouldn't put the proceeding paragraph in an <aside>. So maybe its name is a bit misleading. But I still think it serves an understandable purpose: if I never read the content within the aside, I shouldn't be confused about anything in the article, but the content in it should either enhance my understanding of the content (e.g., example 13 in the spec adds background info about a country that might help an unfamiliar reader) or give me additional functionality, like a sidebar with links or buttons.
I think this is sort of an inherent problem with trying to fit any rigid spec to human language: we want the spec to be written using words we understand, but human language is incredibly fluid and non-rigid, so there are bound to be confusing cases where its unclear which element to use, etc. But I still think there are clear black and white areas, even if there are lots of grays in between.
All that said, I'm interested to hear your feedback, and I'm very interested to read more about the problems people see with the spec; it should be helpful in explaining it better down the line. Thanks for pointing this out to me!
I think part of the issue we run into is that the human language being used to describe this is specifically the language of print layouts like newspapers or magazines. That language was far more known back in the late 90's early 00's but more and more developers are going to be seeing this through web-first eyes.
Your explanations are spot-on though. Even with aside, while we might see it as vague in its contents, you nailed the purpose.
Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
Thanks! And yeah, I agree, the farther we get from the days of mostly-print-media, the less obvious the metaphors become.
I also think with <aside> specifically there are sort of two competing metaphors: the "sidebar" layout element, and the semantic "aside", for tangential info. These are really two very different things, but the spec currently allows for both, which is confusing. As I understand it from some googling, the spec initially only allowed for the semantic usage, and did not recommend using <aside> for sidebars with content unrelated to the main content, like navigation links, etc. But the spec was later amended because of common confusion and the perceived need for a sidebar element to explicitly allow both usages. I'm unsure how I feel about that move.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Good article!
However, I have strong and complex feelings on this, being interested in the semantic web since 2003 and remember ardently following xhtml1.0 strict standards.
main: great, good.
header/footer: awesome, thanks
nav: oh wow how did we live through xhtml without it?
article/section/aside: wow, trash, wtf?
Article, section and aside are so vague that they semantically mean about the same thing as div. You still have to drop identifying classes on them to actually note what they are intended to contain.
Comments/assorted widgets/supplementary info can be articles, but also can be sections, but can also be asides or contain or be contained by any mixture of the above. I'm not saying div is the gold standard, but this is one area whatwg kinda dropped the ball. Semantically, it doesn't say what it is any more than div does.
I'm not alone here, either.
That's a very interesting perspective, genuinely, and I'll have to think more about it.
But my initial reaction is that I think article and section at least have pretty clear meanings:
<article>should be used only for a high-level portion of the document that is sufficiently independent that if it were plucked out of your page and dropped into another page, it would still make perfect sense, like a blog post or tweet.<section>is a block that doesn't meet the above independence criteria, because it only makes sense within the context of the surrounding content, but that you would list in your table of contents.An
<aside>is, admittedly, a bit more vague: is a "note" block in the middle of your text an "aside"? I often use phrases in my writing like "as an aside, ...", but I wouldn't put the proceeding paragraph in an<aside>. So maybe its name is a bit misleading. But I still think it serves an understandable purpose: if I never read the content within the aside, I shouldn't be confused about anything in the article, but the content in it should either enhance my understanding of the content (e.g., example 13 in the spec adds background info about a country that might help an unfamiliar reader) or give me additional functionality, like a sidebar with links or buttons.I think this is sort of an inherent problem with trying to fit any rigid spec to human language: we want the spec to be written using words we understand, but human language is incredibly fluid and non-rigid, so there are bound to be confusing cases where its unclear which element to use, etc. But I still think there are clear black and white areas, even if there are lots of grays in between.
All that said, I'm interested to hear your feedback, and I'm very interested to read more about the problems people see with the spec; it should be helpful in explaining it better down the line. Thanks for pointing this out to me!
I think part of the issue we run into is that the human language being used to describe this is specifically the language of print layouts like newspapers or magazines. That language was far more known back in the late 90's early 00's but more and more developers are going to be seeing this through web-first eyes.
Your explanations are spot-on though. Even with aside, while we might see it as vague in its contents, you nailed the purpose.
Thanks! And yeah, I agree, the farther we get from the days of mostly-print-media, the less obvious the metaphors become.
I also think with
<aside>specifically there are sort of two competing metaphors: the "sidebar" layout element, and the semantic "aside", for tangential info. These are really two very different things, but the spec currently allows for both, which is confusing. As I understand it from some googling, the spec initially only allowed for the semantic usage, and did not recommend using<aside>for sidebars with content unrelated to the main content, like navigation links, etc. But the spec was later amended because of common confusion and the perceived need for a sidebar element to explicitly allow both usages. I'm unsure how I feel about that move.