We’ve discussed a lot of new elements here at HTML5Doctor, but the
article element has somehow escaped the microscope… until now!
article is one of the new sectioning elements. It is often confused with
div but don’t worry we’ll explain the difference between them.
What the spec says
Thankfully, the spec is short and sweet:
articleelement represents a component of a page that consists of a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.
In addition to its content, an
<article> element typically has a heading (often in a header element), and sometimes a footer. The easiest way to conceptualise
<article> is to think of its use in a weblog, as mentioned in the spec’s examples “a blog entry” and “user-submitted comments.” Here at HTML5 Doctor, we wrap each weblog entry inside an
<article> element. We also use
<article> on ‘static’ content pages, like the About and Contact pages, as
<article> can be used for “any other independent item of content.” The tricky part is, what exactly is an independent item of content?
The smell test for going independent
An independent piece of content, one suitable for putting in an
<article> element, is content that makes sense on its own. This yardstick is up to your interpretation, but an easy smell test is would this make sense in an RSS feed? Of course weblog articles and static pages would make sense in a feed reader, and some sites have weblog comment feeds. On the other hand, a feed with each paragraph of this article as a separate post wouldn’t be very useful. The key point here is that the content has to make sense independent of its context, i.e. when all the surrounding content is stripped away.
<article> in use
We only have a title and some content, but it’s enough to make sense on its own (assume there’s a lot more content about apples ;-)
<article> <h1>Apple</h1> <p>The <b>apple</b> is the pomaceous fruit of the apple tree...</p> ... </article>
A published date leads us to add a
<header>, and there’s also content that would be suitable in a
<article> <header> <h1>Apple</h1> <p>Published: <time pubdate="pubdate">2009-10-09</time></p> </header> <p>The <b>apple</b> is the pomaceous fruit of the apple tree...</p> ... <footer> <p><small>Creative Commons Attribution-ShareAlike License</small></p> </footer> </article>
<article> with comments as nested
This example shows a weblog entry with comments. Each comment can be marked up as an
<article> within the containing
<article> <header> <h1>Apple</h1> <p>Published: <time pubdate datetime="2009-10-09">9th October, 2009</time></p> </header> <p>The <b>apple</b> is the pomaceous fruit of the apple tree...</p> ... <section> <h2>Comments</h2> <article> <header> <h3>Posted by: Apple Lover</h3> <p><time pubdate datetime="2009-10-10T19:10-08:00">~1 hour ago</time></p> </header> <p>I love apples, my favourite kind are Granny Smiths</p> </article> <article> <header> <h3>Posted by: Oranges are king</h3> <p><time pubdate datetime="2009-10-10T19:15-08:00">~1 hour ago</time></p> </header> <p>Urgh, apples!? you should write about ORANGES instead!!1!</p> </article> </section> </article>
You can use the
<section> element to split the article into logical groups of content with headings:
<article> <h1>Apple varieties</h1> <p>The apple is the pomaceous fruit of the apple tree...</p> <section> <h2>Red Delicious</h2> <p>These bright red apples are the most common found in many supermarkets...</p> </section> <section> <h2>Granny Smith</h2> <p>These juicy, green apples make a great filling for apple pies...</p> </section> </article>
Where appropriate a
<section> element can contain
<article> elements. We already saw this in the comment section example above, and other common examples are the homepage or category pages of a weblog:
<section> <h1>Articles on: Fruit</h1> <article> <h2>Apple</h2> <p>The apple is the pomaceous fruit of the apple tree...</p> </article> <article> <h2>Orange</h2> <p>The orange is a hybrid of ancient cultivated origin, possibly between pomelo and tangerine...</p> </article> <article> <h2>Banana</h2> <p>Bananas come in a variety of sizes and colors when ripe, including yellow, purple, and red...</p> </article> </section>
<article> for a widget
The specification also mentions that an interactive widget can also be an
<article>. The example below shows how the markup might look for an embedded widget from somewhere like Widgetbox.
<article> <h1>My Fruit Spinner</h1> <object> <param name="allowFullScreen" value="true"> <embed src="#" width="600" height="395"></embed> </object> </article>
You may have noticed the
pubdate attribute in these examples.
pubdate is an optional boolean attribute that may be added to one
time element within the
<article>. If present it indicates that the
<time> element is the date the
<article> was published. It can be written in several ways, the most popular being:
You could think of these as HTML and XHTML-style — the end result is the same so use the style you like. Note that
pubdate applies only to the parent
<article> element, or to the document as a whole.
The difference between
There’s been a lot of confusion over the difference (or perceived lack of a difference) between the
<section> elements in HTML5. The
<article> element is a specialised kind of
<section>; it has a more specific semantic meaning than
<section> in that it is an independent, self-contained block of related content. We could use
<section>, but using
<article> gives more semantic meaning to the content.
<section> is only a block of related content, and
<div> is only a block of content. Also as mentioned above the
pubdate attribute doesn’t apply to
<section>. To decide which of these three elements is appropriate, choose the first suitable option:
- Would the content would make sense on its own in a feed reader? If so use
- Is the content related? If so use
- Finally if there’s no semantic relationship use
Dr Bruce has written HTML5
<section>s, what’s the difference?, so we recommend reading that if you are still fuzzy on when to use
Hopefully this post has given you some insight into the correct use of the
<article> element. Do you have any other examples that you can share for using
<article> in your HTML5 markup?
I’m also keen to hear your thoughts on the confusion between the
<section> elements. Do you think the distinction between the two is clear?
103 Responses on the article “The article element”
Ok, how about this: excerpts. Of blog posts, news articles, first photo of a set, etc.
It makes sense to put them in RSS feed, but they are not self-contained nor complete.
The section/article differentiation definitely is a weird one. It’s the widget example that throws me. Your guidelines state that if the content makes sense in a feedreader then use <article>. But a widget wouldn’t make too much sense in a feedreader would it?
The spec itself seems a bit wooly, which I think is the possible source of the confusion.
I understand widgets as something that you can embed into your blog – recent tweets, flickr photostream, upcoming events from Google Calendar. This kind of widget (or gadget) holds distributable content.
[…] This post was mentioned on Twitter by Rich_Clark, Denis Boudreau, Natalia Ventre, Nicolas Hoizey, Robert Visser and others. Robert Visser said: "The article element" /by @leads on @html5doctor via @Rich_Clark http://j.mp/cYxCYt #html5 #webstandards #webdesign […]
Yeah, it makes more sense if you imagine surrounding content (“Here’s a slideshow of my dog”). Doesn’t help I suppose that a widget could be virtually anything!
I still wonder what pubdate is for. Scratch… scratch…
@riddle I think that excerpts etc are distributable so it makes sense to wrap them with an article element. I tend to find quite a few folks that only publish the excerpt in their feed. The same goes for news articles, photo’s is more tricky and I guess the easy answer is ‘it depends’. However, if it’s just post titles, probably not.
@Philippe – Pubdate? Usually every Friday for me. Ba-doom!
You lucky guy Stuart. I must wait saturday. ;)
[…] This post was mentioned on Twitter by Brian Lang. Brian Lang said: @nettuts re:Confession (again) Hope these help – Section Element: http://bit.ly/ahX8R3 – Article Element: http://bit.ly/bjJAiR #html5 […]
@stuart the widget one is a bit more of a “it depends” situation.
The spec gives an article/widget example, so just because it may not be suitable for a rss feed it can still be in an article tag if you deem it an seperate content block. The title of the widget might be in the rss feed as a link to the page.
Are <article>s really ok for comments? They don’t make sense on their own outside the context of the actual article IMO. A list in a <section> is still the more semantic option I’d have thought. What do the Doctors think?
I agree with Robert on comments; they don’t make sense as a separate entity (they relate to an article whereas an article doesn’t need comments) and consequently they don’t pass the could they be syndicated? test. Technically they could, but you can also syndicate bleeps and pictures of dots.
I put them in an ordered list in the article
footeron my site as you could — at a stretch — argue they’re footnotes. I guess you could even argue they’re
asidess. But they occupy a bit of a strange place. Too late for a
[…] The article element | HTML5 Doctor […]
[…] The article element | HTML5 Doctor When and why to use the HTML5 article element, and how it differs from other similar ones. (tags: web-standards html html5) […]
I also agree with Robert and Leon. Without the context of the blog post, the comment won’t make sense by itself. Unless the blog post is referenced or linked to in a header element of the comment article. That could make putting a comment in an article element make sense.
My yardstick/nose tells me that comments aren’t exactly void of context. A comment by itself, without the article or without the surrounding comments is mostly useless. Comments are usually “in reply to”, so I am a bit surprised you would consider using the article element for that.
PS: I see I’m not the first one to find myself confused over this example :)
@Robert, Leon & Dylan. I see your point however comments are generally available via syndication. Usually each comment in the feed says “Comment on The article element” that does give it context.
@Leon, this shouldn’t be taken as gospel but I imagine that we won’t see a
commentelement. I believe that reusing an
articlefollows HTML5’s design principle for not reinventing the wheel, which is probably why it’s implemented this way. However maybe somebody on one of the working groups can confirm?
I’m using for the main text of a website (hotelteti.com), to differentiate it from other non-semantic DIVs, but I suppose I should use . What do you think?
Note: check “<B>apple” in the first example.
A comment cannot be considered as an article or an independent unit as its context mainly depends on the main blog post and sometimes on some previous comment itself.
IMO the article element has been proposed to point out the most important content of the page (which will be the article for a static page and post entry for the blog post). This will help the search engines as Google to differentiate between the main intended content for the page and the other surrounding text. This will help them determine which links should hold more weight (within article) and ones with less weight (sidebar/footer links). Thus it would be expected that each page should have only one article element on each page (unless more than one full blog entries exist on one page, as in main page of a typical blog).
And for negative side of the article element, it will help scrapers to efficiently extract content from sites to add to their splogs.
If you want to display recent comments in your blog’s sidebar, you won’t use <article> because they are not independent in context of their parent content – in this case sidebar section.
But if you have a complete blog post and you encapsulate them in its <article>, you have a different situation:
Now each comment is self-contained piece of content which makes sense on its own, but only being in the parent <article> – take it outside parent <article> and it doesn’t make sense. But when published under blog posts, you can delete other comments and this nested <article> with comment will make sense.
This is how I see it.
I opened a can of worms there!
@Rich_Clark I can see your point re. syndication although in the context of the blog post itself <article> is still semantically redundant. For marking up feeds or HTML emails of the comments then it makes perfect sense but otherwise it feels a bit wrong to me.
Still, the good thing about HTML is that a page will be usable whichever markup style the author prefers. Debates on semantics are like GCSE RE questions! (ie. agree, disagree, depends on the situation)
@riddle – yes, the examples above have the comments marked up as nested articles. Although they probably wouldn’t be in a feed, the main article would be.
The RSS feed suggestion is a guideline. Also consider a print preview – what would you expect to see of this page for example? The header/logo – yes. Bnd this main article is really what is necessary when you print.
In your nested sections you use h1, h2, and h3, but I understood that HTML5 was going to set the heading level automatically depending on the position in the tree. Some early articles on HTML5 talk about a “h” tag, but that appears to have been dropped in favour of using h1 throughout – possibly for backward compatibility.
I’m writing this because I can’t get the expected functionality to work in any of the semi-compliant browsers (like Chrome) and everybody keeps writing about VIDEO tags and ignore this most useful of features.
A bit confused by the article tag when it comes to the blog comments example. Most of the comments in this thread certainly don’t stand on their own, do they? And what, speaking of the same example, makes the comment’s meta data a header, and not a footer? Quoting the spec: “A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like”
How about this for an example. Take the HTML5 Doctor’s categories (that are currently in the sidebar) and create a seperate page for them. On that page you list all the categories and under each category list all the entries that are tagged with that category.
The entries are obvioulsy articles, they make sense on their own and in an RSS reader. What I’m waivering over is the categories listings. My instinct is that they would also be articles, they seem to make sense on their own? But I’m unsure if section may be more correct.
Im little bit confused by article tags.if want to post something we will type in the comment box and enter,but i never know about this tags
You make my life so much better. I was struggling to see any difference between article and section. But you’ve helped me.
Regarding the use of the <article> tag for comments:
I see the logic behind both sides of the discussion. It makes sense to use the <article> tag when each comment contains a statement like “Comment on [article name],” just as you would use the <article> tag for the original blog post even when the original post is a reply to something else on the web.
However, as I see it, using the <article> tag for comments implies that you expect all future comments–which you haven’t seen yet–to be self-contained and independently redistributable. But we can’t make the assumption that all our users will make well-written comments that will hold up if taken out of context.
In addition, some comments are replies to previous comments rather than the original article. Even if a “reply” feature is available on the original article page, not all users will take advantage of it. Comments often do truly depend on other comments, if not an entire chain of comments.
I’m not saying that the <article> tag is completely inappropriate for comments, but as with all semantic tags, one should take all of this into account and decide whether or not the <article> is appropriate given the particular website, blog/article, audience, and CMS/application features. Moreover, avoid any assumptions about what might end up on your comments page.
I’m interested in hearing the doctors’ thoughts on that idea…thanks!
I have one question:
Can I use the tag “article” > “section” and inside in “section” put the tag “article”?
When I first saw this I just thought horrible semantic markup, and my opinion hasn’t changed. If HTML5 is trying to represent and incorporate current web 2.0 then please call it like it is, create a tag called
<comment>for that is what we see and that is what they are……
One “would” too many perhaps?
i tend to stick to the key point: the content has to make sense independent of its context, i.e. when all the surrounding content is stripped away.
I think @Riddle’s first comment and @Richard’s response to it may have touched on this, re. excerpts: what would be the critical cutoff point at which you would no longer use an article tag? For instance, a set of search results or a category menu, where you list a related or sequential series of ‘articles’ – but you’re not providing the full content. If you were just displaying the title with a link – would each result just be rendered as a list item, and you wouldn’t bother with the article tag? What if we add an excerpt, some metadata (author, date etc) and an image (but still not the full content)? Would this still be just a list OR would each list item now need to contain an article tag to wrap this info (even though you need to click the link to get to the actual full article)? What’s the minimum criteria?
(…and on the ‘comments’ issue, I’d agree with Robert, Leon, Dylan, and Neils – they tend to be sequential, and can refer to each other as well as the original article, so I’d include them as an ordered list within a section, inside the main article… I don’t think they’d always qualify as an aside, and I’d use the article footer for additional article info, such as author info or other metadata that isn’t in the article header.)
Really, i appreciate a lot this blog and the work you’ve done, the articles and explanations are great and i’ve learn a lot of things here. But sometimes you guys go too far for me !
Obviously the article tag is for the main content (i would say : for the article)
and the comments are related to the article and are not the article himself.
I guess this is how a lot of webmasters will understand this. And not only webmasters.
If you point a blog comment to your grandma or your teen, how will they name it ? article, really ?
And the section tag will surely be used to surround several articles, like a blog category. (or… guess what : a blog section !)
All this below the new “header” tag, and above the new “footer” one…
i Guess 99% of webmasters will use those elements like that, and i think they’ll be right !
Really, i don’t like the way some simple things become confused because of the interpretations we have to do to understand fully how the W3C use words that have already a meaning>. If our interpretation of a word leads us too far from his original meaning, be sure that people won’t follow ! They will use tags as they understand it immediately, without the w3c doc step… So here is where i want to go : using tag for what they really mean, and keep it simple !
Personally, I see nothing wrong with using articles for self-contained comments.
Within the context of this article, okay – it may not immediately graduate the sniff-test.
But then there are times where the dress shirt you pick up off the floor may and or may not immediately pass the sniff-test, either (I’m kidding – I’m typically a single-use kind of guy).
There’s a grey area, where you have to stop and ask what’s acceptable.
And luckily, we’re provided with some standards here (a lot more than can be said for the sniff-test, in general).
The standard actually says “reusable”, and doesn’t stop at “redistributable”.
Think of a website for a newspaper.
Now, imagine that on the index page of the site, you’ve got your header at the top of the page, and then the entire middle section of this long-scrolling site is just the front page of each paper from the last three days.
The entire middle column, holding all three papers would be a “section”.
Each paper, itself, would be an “article”.
Each contextual section of the page would be a section.
Each article within the given contextual section (sports / local / fiscal / political) would be an “article”.
Each article could have different sections, denoting changes in context for that particular piece, which all tie together to form the whole story.
If it was a mashup or a month-end/year-end roll-up, it might be possible to have instances where you’d even see “articles” within those sections, within the piece, within the section of the paper, within the paper, within the “last three papers” section of the site… …we’re stretching it now, but it’s still theoretically possible.
Like I said, the standard actually draws the line at “content-complete, context-complete AND reusable”.
Imagine a Letter To The Editor:
Is that letter published underneath the article it was written about?
Absolutely not. In fact, that’s typically impossible, given that newspaper subscribers would be required to READ the article before replying.
Is it possible, however, that the letter itself is an article?
It is housed within the “comments” section or the “editorial” section or wherever…
Who wrote it.
When it was written.
What it was written in response to.
What the person thought about what they are responding to.
Could that letter theoretically be picked up, in its full form, and moved elsewhere within the paper?
Could it have been printed on a different date, in a different edition of the paper and still be content/context-complete?
Could it be printed multiple times in the same paper?
Could it be copied, and have the copy of that letter printed in a sidebar, elsewhere on the paper’s website, in a “most-hated letters” widget?
Yeah. It could. Without worrying about the presentation layer of it, in terms of context and content, the whole thing could easily be added to that separate widget, or moved to a part of a discussion forum, or wherever else, and still make sense within its own little self-contained world.
That letter to the editor could be turned into a Tweet, or it could be pushed to a Facebook update, or it could be rolled into a blog…
…but WHAT you’re doing with it is inconsequential, which is why the “RSS sniff-test” comes back with a negative-match, here.
Can I take this comment that I’m writing right now, and take my user-name, the pubdate of this comment (look at that – there’s even a use for article-specific attributes), include the href-to, and name-of the article in question, and place that whole thing within a different view / different section / different widget on another page on HTML5Doctor and have my post make sense within its own self-contained world?
I think that the answer is “yes”.
I think that this comment could easily be tossed into a content-aggregation widget on the homepage, and posted under the “least-read comments” section.
Even the spambot comments could be harvested and posted under the “least-useful comments” section, and they’d still be context-complete. You’d have the whole story: (How, whom, where, what, why and when), regardless of it being one worth reading.
And now, even outside of the context of the original newspaper article which the letter was referring to, and within the context defined within the article’s new home “section”, the article is still self-supporting.
Maybe it’s not suitable for certain kinds of delivery. Maybe it isn’t suitable for all contexts. Nothing is context-agnostic, aside from post-modernism and avant-gardism.
1) Is the element’s primary purpose to hold elements which contain human-digestible media (text / photos), rather than to hold elements for layout or styling?
2) Is it content-complete (not dependent upon nearby non-child elements, to hold missing content)?
3) Is it reusable, WHERE SUITABLE, in its entirety, without rewording, or changing any of the contained markup?
It’s an article.
A couple of people have asked:
“What about user-posted comments that are awful, or have little content.”
Well, what about blog-posts that are awful and have little content?
Theoretically, they’re still blog-posts.
Within the world of HTML markup, we can’t be held responsible for what people fill the spaces with.
We can only be held accountable for giving them a proper backbone with which to fill.
That means that if you WANT to use “article” as your container for user-posted comments, you need to have EVERYTHING you need laid out within the confines of a single comment, in order to delimit it as content / context-complete.
You couldn’t make it a simple text-field for a response, and wrap that response in an “article”, because then it’s NOT reusable – you couldn’t put it in a widget and have it stand apart on its own.
You’d require your comment to be structured to have enough data in order to MAKE it be suitable for reuse.
Maybe that’s title, date, author, author-image, e-mail, website, response-number, response-text…
Maybe that’s what you require in your template for each and every user-comment (looks a little like a forum-post, no?).
At that point, each forum post should be able to be pretty modular.
Maybe all you need for modularity is author and response, because the context for your multiple sections which this single article can be reused in is really, really lax?
I wouldn’t necessarily think that’s a good thing…
Maybe it is. Maybe that really is all you need for your particular setup, in which case, author and text is perfect.
If you can show that your text can then be applied (content-complete, context-complete and self-contained) to different widgets and different page sections (or Facebook / et cetera) as-is, then you’ve got an “article”.
Gosh @Norguard, did you write such a long coment to make a point about comments being articles too ;-)
I think a lot of the endless discussion over semantics unleashed by the HTML5 specs ultimately come because they have picked confusing names for their tags – aside and article being the worse. They probably spoke about these words for so long they ended up forgetting what they actually mean to the layperson.
Article was a bad choice because it’s too tied up with publishing / blogging – what about product listings on ecommerce sites? or train timetables? calling them articles feels wrong (even if the word ‘article’ can also be used as ‘an article of clothing’ etc).
And even within publishing, as amk points out, ‘article’ intuitevely means a piece of writing by the author of the page, not a comment.
Having said that, I mentally translate ‘article’ to ‘main content’ – so in a blog, where people comment to say ‘thanks for the tip’ or such like, I wouldn’t use it, but in a public forums or a site like this, where the discussion is as important as the main article, I would.
What browsers support these two tags? How can I find that out? Also, your comments section is all messed up in Chromium 12.0.7 on Ubuntu 11.04..
I hadn’t anticipated writing quite that much.
Frankly, at that length, I could have saved some time and just wrote out the full source for a random blog-site, replete with multiple blogs, each replete with multiple monthly / annual roll-ups or mash-ups, each, themselves outlined with their own section or article.
The trouble with aside was understandable :
They gave it a name where people took it to mean one thing, when it meant another.
Then the spec bounced around a bit.
Personally, I’m glad it does double-duty, so long as people know what it is that goes in each iteration of the element.
The fun bit is that I’m remembering “PopUp Video” now, and most of that entire series was based on what could be conceived as both versions of “aside”, used throughout each song.
With “article”, it’s unfortunate that there is confusion there.
I understand why. Really, I get it. We call things articles all the time. Even when they wouldn’t be. And likewise, we refuse to call things articles, even when they are.
An “article of writing”, “household articles”, and “articles of law” are all things, and all have very different connotations to those that we’re accustomed in daily life.
Really, they’re just singular items. No more, nor less than singular.
There may be more than one article holding together a legal bill / constitution (sections full of articles, and articles full of clauses)…
…much like there may be more than one article of clothing standing between you and an indecent-exposure charge (depending upon which article is chosen).
But every article has one thing in common: they’re all complete in and of themselves.
The more frustrating bit is this: given the meaning of “article” (the abstract meaning, rather than the tabloid meaning), what else could that element be named, other than “completeThing” or “selfSufficient”?
And the other frustration is that if people were to hold onto that concept of it (again, rather than a tabloid article), they’d have much less a problem of figuring out the difference between a section (which might group similar articles), and the articles, which are completely self-contained.
So like you said, the latter element really comes down to how people interpret it.
And yes, typically, I’d be loath to personally hand-wrap “plus-one bro!!!! LOL” in an article element, with a time and pubdate.
Truth be told, I may be more tempted to wrap a fist-bump upside their head…
But I don’t get to control the quality of the discussion as it comes from other people – much as I can’t control the quality of 5-word blog posts, or shoddily written sensationalism pieces (likely also wrapped in “article”) – I merely control the semantics which describe the discussion, and my own personal responses.
i think article is independent because it can have header, footer, pubdate and address.
comments belongs to footer, but since comments usually link to other semantics like pubdate and address, you can wrap it inside article, inside the footer of that article.
Hi! I ran into a problem with ‘time’ and ‘pubdate’, maybe somebody could help me.
I have list of articles:
<p><time datetime="2011-06-22T09:57:00" pubdate>22 june</time>, Author name</p>
And as I can see everything is alright, but w3c validator says: ‘Attribute pubdate not allowed on element time at this point.’
Ok, I’ve solved the issue. The problem was in datetime format, it requires ‘Z’ or TimeZone at the end. So in my case it has to be like 2011-06-22T09:57:00Z
@Mike Did you have something to add to this conversation, or are you simply pimping your site? [my apologies to other readers for being so blunt, but i am tired of people using reputable sites to promote their own half-baked kaka]
As he opened the issue however if you follow his link, please do not use the paradigm from @Mike’s current examples by starting the content of an article (in the generic sense, not the publishing sense) with an h2 simply because an h1 is previously used on the document. The h1 should gracefully be demoted (if needed) by the browser according to the spec. If it isn’t or if you need something other than the previously defined styling, you can always style it as desired in your CSS. More importantly — as stated — the content within an article tag should be able to stand alone. As such, if a heading is needed, it should always make sense even if the only item of content on the page is the article. Thus, start with an h1 in your sections and articles, no exceptions needed.
For those that read the Doctor’s article (sorry, i could not resist) and subsequent comments this final admonition is pedantic, my apologies, but some may have skipped down a bit in the conversation:
The point of these additions to the spec (section, article, et al.) is to provide semantics when desired to the content of our documents. It is all about the content, and how future users and systems will parse that content, not how we want it to appear today to a given user (CSS does that just wonderfully). If semantic parsing of the content is not important for a given site, no problem, there is no need to use the new features being discussed here.
@Dao Thanks for the comments and for reference I’ve marked Mike’s comment as Spam (plus a couple of others) for anyone who can’t see it!
Would a slideshow be wrapped within a <section> element and then each slide within <article>? Or would it be within an <aside>? I’m wanting to include a slideshow above my main content to include other tangentanial content; however, I’m not sure if the nesting should be <section><aside></aside></section> or <aside><article></article></aside>. Or something entirely different
Hey firstly not a bad post. I am not surely i entirely agree with this point of view. I would like to hear all the information before
(MUHAHA sounds like I’m writing a letter)
Here’s my personal interpretation of some new HTML5 elements.
<section> is an enhancement of <h1-6>.
<h1-6> is capable of creating a section themselves, but the way they decide what content should go inside their section sometimes less desirable. So <section> is our way to force the sectioning.
<aside> is our way of saying “this content is not part of the message I’m trying to deliver with this article”, we put it aside.
Most of it’s content only make sense in the context of the site, such as ads, site’s list of recent articles, navigational links for logged-in users of the site.
Most of it become less desirable when we copy-pasted that article out of the context of the website, and place it in other media.
<nav> is a bit tricky. Not all navigational links should be made a <nav>. The webmaster should decide which navigational links benefit the site’s visitors the most, so to focus their attention there.
I also forgot to mention that <nav> inside an <article> has even more strict rule. Another reason why an <article> is said to be independent.
Disclaimer: Again, this is just my personal interpretation. I would love to hear what others have on theirs. I have talked about it a few times and each time broaden my perspective.
Err, I made a mistake in my previous comment ^^, about comments being marked up as html5 article.
The comment’s content is not in an <article>’s <footer>, but the comments’ pubdate is, as per whatwg example.
(No idea why they would print out footer upfront in those html markups).
I’m not sure if that was the answer I was looking for but in the end, I decided to wrap the slideshow in its own section, as every page will have a “slideshow” section, and put each text/image slide into its own article.
That way, the slides (articles) are relevant to the content of THAT section while the “posts” section has its own articles (posts) and its own aside (sidebar).
It’s a bit confusing as to what “div” I should replace with section or article and what should stay as a div. :) I wish there were more example sites truly showing how things should be done.
That reminds me, another concern that I’ve had was the use of “section”. When creating a two-column blog layout, is the two-column wrapper a section with a div for posts and an aside as a sidebar or is the wrapper a div and the posts wrapper a section with its sidebar aside companion.
hey this is really very nice article and makes things very clear.
One thing i still have trouble with to grasp on the article element is the self containing part, it’s pretty clear what it stands for, but in certain cases i am having difficulty to decide what is best practice.
For example look at this code:
Title news post
A problem i ussualy have with the above situation is whether or not i should keep the header nesting going h1 > h2 > h3 etc. According to the spec a article is self containing, should it not always have a h1 even in the above situations? And how does this inflict the document outline or semantics?
Sorry i forgot the brackets. Here is the example code.
<h1>Title news post</h1>
I’m still confused where to put article, header, hgroup, and section.
In modern browsers that get the layout right, you can have nested sections in sections in articles, in sections…
Each one can have its own header, hgroup, h1 and h2, if you so desire.
As long as the nesting of your sections makes sense (to the browser), that’s exactly the intended outcome — to be able to write self-contained modules (a post, an update, an article, a tweet, a comment), and have it use its own Hx hierarchy.
In older browsers, this isn’t guaranteed to make sense to the browser’s layout engine.
So while the ultimate goal is to be able to go:
nature’s stupidity meter?
….blah, blah, profound-blah.
this was written by Me™
This spoke to me.
It told me to burn things.
the preceding opinions are all awesome, and do not
reflect the views of the awesome-impaired
The sections and articles can all have their own headers, footers, hgroups and h1-h6.
But older browsers may still expect to draw the layout as if sections were still being controlled by the hierarchy of the h1-h6 tags:
In this case, the h2s might represent your “sections”, and the h3s your articles within each section.
I’ve seen some funny CCS applied to h1s and h2s inside of nested sections (where everything is browser-default), so that’s a consideration (ie: always style the headers for each of your nested sections, lest you have a tiny h1 and a huge h2).
But aside from that, I haven’t seen anything horrifying.
See the example above for what might be considered an appropriate use of sections/articles/headers/footers.
Escaped elements here:
<h2>nature’s stupidity detector?</h2>
<footer>written by me™</footer>
by: <span class="author">bob</span>
on: <time datetime="2012-1-27T12:40:37"
<p>This spoke to me.<br />
It told me to burn things.</p>
<img src="my_sig.png" />
<small>the preceding opinions are those of someone awesome,<br />
and not necessarily reflective of the views of the<br />
hey norguard, do you think having multiple H1 on webpage is good idea, I am also not sure but I think web page must have only 1 H1. it has some SEO benefits also.
The idea is that *eventually*, these content sections won`t just be “pages”.
<article>elements are intended to be moved around.
Onto other people’s pages as widgets.
Even just into other sections of your website (like having a “Most-Recent Comments” section on your front page, or adding your blog post to a blog roll).
All without having to rewrite any of the html, just because you changed its place.
So *eventually* you’ll want to use many H1s.
Why? Because who knows what those other pages are going to have on them.
Using the old rules of old browsers, you could use an H3 and *still* break the layout of somebody’s page (if there’s no inline-frame, and the person uses a lot of H4s).
There’s no way of knowing what’s on the other side of the widget.
So that’s why section and article elements have been made to have their own layout (ie: why each new Section supports its own Hx hierarchy).
Right now, people are using sections/articles, and they’re keeping the same H-levels that they normally would.
There’s nothing wrong with that.
And for old browsers, it’s the most compatible way of doing it.
As for SEO, I wouldn’t worry too much about that.
Once upon a time, this was a big deal, but Google has come a long way in terms of what they collect and how, and they have one of the most-compatible html5-and-friends browsers out there.
You’re still only putting 1 H1 in the body tag.
And each other H1 is inside of a new section/article element.
When Google crawls your site, they will see this.
Other engines, I don’t know…
But even as of three years ago, Google suggested using multiple H1s, if you have very good reasons for using multiple H1s — and that was for having multiple H1s in the body element (not in section/article elements).
Hey Norguard , Thanks a lot for the info, found it very useful. if possible can you share some articles where I can find the best use of HTML5 elements for SEO.
I’d love to, but there really isn’t a whole lot of information specifically about html5 (/html living-standard) elements and SEO.
And realistically, there isn’t a whole lot of need to do so, either.
As the web progresses, Google will do its best to pull the most relevant information out.
There are ways of helping the system:
– learn about the <link rel=”canonical” /> tag
– learn about microformats and microdata
( Google has a Rich Snippet Testing Tool for testing your microdata, as their engine should see it )
– use all of the elements as they’re intended to be used.
Don’t try to cheat Googlebot
– check out the Google webmaster series on YouTube.
Matt Cutts is awesome.
The more we all use them as intended, the better Google will treat us all.
This article was been translated into Brazilian-Portuguese and is hosted at: http://www.maujor.com/blog/2012/01/29/o-elemento-article-da-html5/
hey thanks norguard , your suggestions are really very useful.
Hello, very nice post.
I’m new to HTML5.
my question is, How to use the html5 tag along with
@takien — check out our article Extending HTML5 — Microdata which covers schema.org.
@Mauricio Samy Silva — thank you! I’ve added a link to your article in “Translations” at the top. Please let me know if you’d prefer “Português do Brasil” instead.
Great! Thank so much, now I finally understood this “perceived lack of a difference“!
@Vladimir I still get
errors on W3 Validator
Attribute pubdate not allowed on element time at this point.
…atetime=”2012-02-08T20:45:19Z” pubdate>February 8, 2012<span class=
using both styles of time zone format Z and +00:00
Unless I am missing something obvious, does this mean the W3 Validator is incorrect on pub-date? Is there a better / different validator?
How did you add the “Z” at the end? On a few of my editor files, I can see the following code:
…a href=”%1$s” rel=”bookmark”>%3$s</a…
Can I add the Z here? Or do I need to try and find where "%2$s" is and edit that?
I’m not sure how to post the code, but this is the section that I think I need to change?
@Jake, I would have hard coded the Z in to test it.
Looking at your code snipped, it looks like WordPress, and the %3 will refer to the 3rd function, most likely the_time(“c”)
The ‘c’ means ISO 8601 which gives a format 2004-02-12T15:19:21+00:00 the +00:00 at the end is a valid timezone.
If this is right there is nothing for you to do in WordPress, it seems it is the W3 Validator that is showing the error incorrectly, in my opinion.
“I still get
errors on W3 Validator”
just want to say that I tested my site again today using the W3 validator and no longer got the pub date errors – so I guess that was a bug & got fixed
Would you recommend to apply styles directly to the ARTICLE? Or should it be treated the same as a SECTION? – To include a DIV within the ARTICLE with the styles applied to that instead?
HTML 5 spec is very straight forward when blogs are concerned, but for me is very confusing to put in different web contexts. Example: I have a session with a list of bands that are on tour. The only thing I got for each content is a thumbnail and the name of the band, and the link leads me to their list of shows. So should I treat this like:
Bands on Tour
Name of the Band
Bands on Tour
Name of the Band
sorry, didn’t use the code tag, basically, should I use Lists or Articles in this case?
This kind of vegetable salads website is excellent data, thank you a great deal.
You have given a good detail of the article but i want to know that how to write css when i am using article inside a section tag or a header tag or aside tag
The patient will need disposition and therefore we will get Dr. hasan thair to dispose of him.”….im am a doctor from UK. palese visit my site
Thank you everyone for making it more confusing. I just need to know if this is ok for a blog post with comments:
<p>Apples are delicious fruits that grow on apple trees.</p>
<h3>Posted by: Apple Lover</h3>
<p><time pubdate datetime=”2009-10-10T19:10-08:00″>~1 hour ago</time></p>
<p>I love apples, my favourite kind are Granny Smiths</p>
<h3>Posted by: Oranges are king</h3>
<p><time pubdate datetime=”2009-10-10T19:15-08:00″>~1 hour ago</time></p>
<p>Urgh, apples!? you should write about ORANGES instead!!1!</p>
<h2>Add your comment</h2>
<label for=”author”>Name (required)</label>
<input type=”text” name=”author” id=”author” value=”” size=”22″ tabindex=”1″ aria-required=”true” required=””>
<label for=”email”>Mail (will not be published) (required)</label>
<input type=”email” name=”email” id=”email” value=”” size=”22″ tabindex=”2″ aria-required=”true” required=””>
<input type=”url” name=”url” id=”url” value=”” size=”22″ tabindex=”3″>
<label class=”screenreader” for=”comment”>Enter comment</label>
<textarea name=”comment” id=”comment” cols=”100%” rows=”10″ tabindex=”4″></textarea>
<input name=”submit” type=”submit” id=”submit” tabindex=”5″ value=”Submit Comment”>
Personally, I like the extra markup of making it an article, and then putting that article inside of a list-item, in an unordered-list.
The reason I do this (same for tweets, or news updates, or whatever) is so that I can use CSS to build a “card” class or a “post” class or a “tweet” class…
And make the band’s card an Article.
Then when I’m building it in JS/PHP/Ruby/whatever, I can put those cards in a list, or I can put one of those cards in a “featured artist” spot, or whatever, and the CSS and the HTML will be 100% the same, regardless of where I stick it on the site.
But then you still have the benefits of putting it in a list, if you wrap each “card” inside of its own list-element, in an unordered-list.
See where I’m going with that?
Personally, I’d probably put each comment inside of an ordered or unordered list, with each “comment” article inside of its own list-element…
…but that’s just me, and isn’t a requirement at all.
Wow. Who would have thought that a simple yet important HTML5 tag such as can be still be missed these days?
I am looking forward to the day when all browsers fully support HTML5. Thank you a great article Tom.
So if someone replies to a comment (article-element) does that comment (article-element) become a child of the original comment or a sibling?
Agree with @yogi that standardization is the real key. I’m not sure it will ever happen, but here’s to wishing…
Just wondering about the “article containing sections” example (and the other way around) why you’ve chosen to use a h2 heading for the section elements instead of using h1 headings.
I have just seen that article and section elements are just fancy div’s with meaningful names.
What if we were to think of “Article” and “Section” as a cardboard or a wood box.
Say we have live ants and dead ants and food. If I were to take the dead ants and put them in a box with food, I would choose the “Article” box.
If I was to put the live ants with food in a box, I would choose “Section”
Hows that for confusion? ;)
I wish there was a rel=”” attribute in sections and following from it, articles.
. . and so on.
Do you mind if I quote a couple of your posts as long as I
provide credit and sources back to your blog?
My blog site is in the very same area of interest as yours and
my users would really benefit from a lot of the information you provide here.
Please let me know if this alright with you. Thanks a lot!
on the using for comments. I don’t think it will be valid in in general blogging sense. e.g. Comments in this page. Since it’s not independent. The comments are strongly related to the specific blog post and written with intent/purpose of being related to this specific blog post.
Also I doubt these comments are generally for syndication.
However I think in a highly specialised cases this may become valid. For instance Amazon/imdb review on a product/film. Or may be incase where specific comments are referenced in. In that sense comments can be contained within at the location where it actually appear. For e.g. articles appear here http://en.wordpress.com/#!/read/topic/html5 should be contained within
Or instance where you would show list of related articles for another article as these articles are written to be independent.
If you go to a site which has lots of articles, or is based around reviews or commentary, they might have a section of the homepage, which is for “recent comments”, and has a list of the most recent comments made in active articles/reviews.
The comments in the list aren’t related to one another, because they all refer to their own parent articles.
And each comment is self-contained.
If I write an article about a movie, my article is still self-contained, even if you haven’t seen the movie.
If my article did a poor job of encapsulating its own context:
“It was awesome because stuff happened and there was a twist at the end and stuff.”
That doesn’t make it less of an “article”, in the semantic sense. It just makes said article poorly-written.
If a reply doesn’t provide any context which can be surmised from the title of the parent article and the body of the comment, then it’s likely a poorly-written reply.
As for “Syndication”: the term doesn’t intend to mean putting it in an RSS feed. That’s a potential use, rather than the principal goal.
Syndication could be as simple as code-reuse, by putting that comment in a list of “recent”/”most-favourited”/”most-useless” comments, on another part of your site.
Maybe on some sites, a comment only needs to be a <p> with a few <span>s, and that’s fine, too.
Personally I think the term ‘syndication’ is poorly chosen. A better word would be ‘sharing’ since it explains better in which cases article should be used. Anything that can be shared, either through RSS, email, twitter, apps (like ‘recent comment’) etc. should be placed in an article. This includes comments.
You do make a valid point and I missed your post on Microdata earlier.
So I guess we need to ensure we extend comment articles with microdata.
or least include role=”complimentary”
So it gives more specific information about “article” used in relation to the main content?
creating is pointless.
<section itemscope itemtype="http://schema.org/UserComments">
<article id="c1" class="comment">
Posted by: <span itemprop="author">George Washington</span>
<time datetime="2009-10-10" itemprop="commentTime">15 minutes ago</time>
<p itemprop="commentText">Yeah! Especially when talking about your lobbyist friends!</p>
@Shavindra: Actually, WAI-ARIA also specifies that comments are role=’article’ and not role=’complimentary’.
But I have some questions:
I’ll use this article as an example. I’ve inspected and saw that you guys are using sections for each part of this article, each one containing a heading. Is this a correct way to use?
My suggestion it’s to use articles inside this big article.
The section spec says:
“The section element represents a generic document or application section…The section element is not a generic container element. “
So, what I missing here?
An article is a complete thing.
Inside of the <article> you need to have absolutely everything required so that you can pick that article up and put it elsewhere on the page, or on a different page, or on a different site, and the stuff inside would all mean the same thing, and be self-contained.
A section is a section. It’s where a logical group of things might live.
Here’s an example:
I have a website.
On that website, I have a list that looks like a CD rack.
It wouldn’t make much sense to make the CD rack itself an article.
Why? Because it’s not a complete thing. Not really. Just like the front-page of a newspaper isn’t a complete thing. It’s a section where logical groupings of complete things reside.
So <section> makes sense.
Okay, next step.
You click on an album in the CD rack, and there’s a nifty CSS transition, while the CD gets pulled out, and lists all of the meta-stuff about the album.
What should the album be? An article. It’s whole and self-contained and it has all of this information nicely wrapped up, so that you could put the same data anywhere else on the net, and it would all make sense as-is, without rewriting any content.
Then inside of that album, you have things like a track-list and a band-member list, and credits and a list of all of the lyrics for each song.
Here’s where things get a little more complicated.
What should the list of band-members be?
If you have content that looks like
members of Nerds with Guitars
– Sean May
— vocals, guitar
– Alex James
— vocals, guitar
Then sure, you could totally make that an article.
Anywhere you put that, in any feed or API, or widget, or whatever, it’s going to mean the same thing.
But why would you want to have something that looks like
For the Record – Nerds with Guitars
tracklist for For the Record by Nerds with Guitars
– Sympathy for the Daleks
music credits for For the Record by Nerds with Guitars
If you did it that way, and made each heading completely redundant, then yes, you could totally wrap each one in their own article, because then you could grab each section by the heading, and anywhere you put it, people will know what it is and what it’s about…
…but you don’t want it to look that way inside of the MAIN article, because that’s just a mess…
You’d like headings like:
Well, what if you all of a sudden took the “music credits” out of this article, and stuffed them in a section which was made specifically to hold music credits?
– David Gilmour
– Roger Waters
– Nick Mason
– Rick Wright
– Sean May
– Alex James
– Eddie Vedder
– Stone Gossard
– Mike McCready
– Jeff Ament
– Matt Cameron
Nobody has any idea who we’re talking about, unless they’re really good at trivia, or Google is their close friend.
If the credits were written with band-name and album-name in the title (or otherwise in the header), then this would make complete sense… but that’s not the content which is presented inside of the main article, and it can only be an article if it’s self-contained and portable.
So it’s a <section>
What about the lyrics?
Well, looking at it objectively, it should probably be a <section> which holds a list of <article>s. Each article being a self-contained thing, which has the title of the song, the band that wrote it, the writing credits for that particular song, the words to the song, the copyright information, etc…
…or just title and words: that’s still 100% self-contained (if a bit confusing, due to frequent overlap of song-names, if put in a list with all lyrics from all bands, but that’s not the <article>’s fault any more than two people tweeting the same thing is)
I hope that helps to point to specific uses for both, which will allow you to generalize how you use them in the future.
As an addendum:
The spec says that <section> is intended for document sections. Maybe these are chapters. Maybe the Table of Contents in a book is a section. Maybe the Index/Codex are sections, if your article is a book.
When it says that it’s not meant as a “generic container”, they’re saying: if you need to put a bunch of things together, to float them left, or you need to put things together just to add an event-listener, or just to get them all to slide when you click a button, or have a drawer of them pop out, when you hover over a menu button, then use a div.
If you can mentally title the section of the content (and often give it a title for your users), and that section can’t be dragged and dropped into a completely different part of the site and still make sense on its own, then it might be happy being a <section>
dlbe a more appropriate choice than
articlefor the example in the A
Great walkthrough, just what I needed. Thank you. :-)
HTML5 Doctor wrote, of article: “An independent piece of content… key point here is that the content has to make sense independent of its context, i.e. when all the surrounding content is stripped away.”
I think you miss the point here. Like all block elements, article is not there to strip away content, but to hold content. What W3 means by “makes sense” is that the physical tag’s logic is to be maintained, and further, that bland one-lunge div’ism is strictly unwelcomed accomplishment for our distinguished new team leader (should the doctor ever be so-inclined as to develop an article, yet)… Perhaps our doctor needs a cup of tea in a common sip-stop. Comparing structural behaviors of div and article and section in relation to each other is fascinating, making for great tit-tat! Lovers only, please. No strippers welcome! Un-lame your prognosis, today.
It was mentioned earlier, but i wonder if using article for products in an ecommerce site is sensible?
Personally I don’t see an issue as it seems the most logical choice for now.. the comments would seem to suggest the same although it was not exactly spelled out which is why I ask.
I’m also using schema.org microdata and i’m feeling like i’ve achieved semantic sanity.
Is it likely a <product> element would ever be introduced or is that just crazy speak?
Wow, I really wish we could do this:
Self contained article goes here.
Comment relating to myPost goes here. Asides should also be able to work this way with a for attribute.
How could Hixie have not landed on including a comment tag when the web is so social?
I think I get what you are wishing for: and intelligently organized semantic.
Focusing back in the direction of W3 now, we are all slipping out on this one. Two (2) actors at W3 earlier this year complained that semantic was unattended:
article ( section ( subsection ) ) real world requirement
There is no subsection element. W3 comeback later this year but now tucked into all the major browsers:
article ( section ( article ) ) ? wtf ?
On thee olde brite side, in plain language: div was bugging out some of the advanced CSS3 features and script. Snuggling article into the realm of div wahteverism cleaned up the bugginess.
Conclusion is this. Web publishing is very newbie and highly dubiously contrived (Chris Coyer’esque there). Check out the Wiki’s info on publishing semantic and it is obvious that an art dating back to Mayan and Egyptian times 5,000 years ago is sorely understated, cum digitalis.
But we all share your enthusiasm, Jeff. Oh, to simply lay out logical tag blocks and sweep our content where it goes! Not in this world. Give us time… and then some.
I just love this article!
Read it so many times and it becomes more and more clear to me, what’s the real deal with <article> and <section> :)
I have two doubts I can not solve my self and the information on web is rather confusing since there’s a lot of situations, perspectives and no enough examples.
1 – What would you use to contain a “Recent Content” block of a blog? This “Recent Content” would wave a table with 25 “a” tags linking to the most recent blog posts. Div, Section or Aside?
2 – Would be possible to put publishing date in the “footer” of the “article”, along with author, comments (link to comment section) and categories? Or would all this “meta” information be properly inside a “aside”?
Thank you for all html5doctor offers us.
Quick question. I have a developer working on a site for me and i noticed that although they have closed tags they don’t have an opening tag.
When I questioned them the reply was that this was html5!
My question was how come you are closing a tag that’s not open in the first place.
could someone please enlighten me on this.
The rules are defined in the Tag omission in text/html section of the HTML5 spec and included in the first section of each element definition. So for example, for the article element “Neither tag is omissible”, which means you must have a start and end tag.
What would be the best way to markup a FAQ page?
Would you do this:
<h2>This is a question</h2>
<p>This is the answer</h2>
<h2>This is a question</h2>
<p>This is the answer</h2>
or would you do:
<h2>This is a question</h2>
<p>This is the answer</h2>
<h2>This is a question</h2>
<p>This is the answer</h2>
Leave a Reply to Shavindra