An article is an independent, stand-alone piece of discrete content. Think of a blogpost, or a news item.
Consider this real-world article:
<article>
<h1>Bruce Lawson is World's Sexiest Man</h1>
<p>Legions of lovely ladies voted luscious lothario Lawson as the World's Sexiest Man today.</p>
<h2>Second-sexiest man concedes defeat</h2>
<p>Remington Sharp, jQuery glamourpuss and Brighton roister-doister, was gracious in defeat. "It's cool being the second sexiest man when number one is Awesome Lawson" he said, from his swimming pool-sized jacuzzi full of supermodels.</p>
</article>
It could be syndicated, either by RSS or other means, and makes sense without further contextualisation. Just as you can syndicate partial feeds, a “teaser” article is still an article:
<article>
<a href=full-story.html>
<h1>Bruce Lawson is World's Sexiest Man</h1>
<p>Legions of lovely ladies voted luscious lothario Lawson as the World's Sexiest Man today.</p>
<p>Read more</p>
</a>
</article>
Other articles can be nested inside an article, for example a transcript to a video:
<article>
<h1>Stars celebrate Bruce Lawson</h1>
<video>…</video>
<article class=transcript>
<h1>Transcript</h1>
<p>Priyanka Chopra: "He's so hunky!"</p>
<p>Konnie Huq: "He's a snogtabulous bundle of gorgeous manhood! And I saw him first, Piggy Chops!"</p>
</article>
</article>
The transcript is complete in itself, even though it’s related to the video in the outer article. The spec says “When article elements are nested, the inner article elements represent articles that are in principle related to the contents of the outer article.”
section
Section, on the other hand, isn’t “a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable”. It’s either a way of sectioning a page into different subject areas, or sectioning an article into … well, sections.
Consider this article:
<article>
<h1>Important legal stuff</h1>
<h2>Carrots</h2>
<p>Thingie thingie lah lah</p>
<h2>Parsnips</h2>
<p>Thingie thingie lah lah</p>
<h2>A turnip for the books</h2>
<p>Thingie thingie lah lah</p>
<strong>Vital caveat about the information above!</strong>
</article>
Does the “vital caveat about the information above” refer to the whole article, eg everything under the introuctory h1, or does it refer only to the information under the preceding h2 (“A turnip for the books”)? In HTML4, there is no way to tell. In HTML5, the section element makes its meaning unambiguous (and therefore, more “semantic”):
<article>
<h1>Important legal stuff</h1>
<section>
<h2>Carrots</h2>
<p>Thingie thingie lah lah</p>
</section>
<section>
<h2>Parsnips</h2>
<p>Thingie thingie lah lah</p>
</section>
<section>
<h2>A turnip for the books</h2>
<p>Thingie thingie lah lah</p>
</section>
<strong>Vital caveat about the information above!</strong>
</article>
Now we can see that the vital caveat refers to the whole article. If it had been inside the final section element, it would unambiguously refer to that section alone. It would not have been correct to divide up this article with nested article elements, as they would not be independent discrete entities, which is why we used the section element.
OK. So we’ve seen that we can have article inside article and section inside article. But we can also have article inside section. What’s that all about then?
article inside section
Imagine that your content area is divided into two units, one for articles about llamas, the other for articles about root vegetables. (Or see today’s Guardian home page with its main news, a section of election picks, a section of “latest multimedia” etc).
You’re not obliged to markup your llama articles separately from your root vegetable articles, but you want to demonstrate that the two groups are thematically distinct, and perhaps you want them in separate columns, or you’ll use CSS and JavaScript to make a tabbed interface. In HTML4, you’d use our good but meaningless friend div. In HTML5, you use section which, like article invokes the HTML5 outlining algorithm, while div doesn’t because it has no meaning. (A great read on the outlining algorithm is Lachlan Hunt’s A Preview of HTML 5):
<div role=main>
<section>
<h1>Articles about llamas</h1>
<article>
<h2>The daily llama: buddhism and South American camelids</h2>
<p>blah blah</p>
</article>
<article>
<h2>Shh! Do not alarm a llama</h2>
<p>blah blah</p>
</article>
</section>
<section>
<h1>Articles about root vegetables</h1>
<article>
<h2>Carrots: the orange miracle</h2>
<p>blah blah</p>
</article>
<article>
<h2>Swedes: don't eat people, eat root vegetables</h2>
<p>blah blah</p>
</article>
</section>
</div>
Why not article? Because, in this example, each section is a collection of independent entities, each of which could be syndicated—but you wouldn’t syndicate the collection as an individual entity.
Note that a section doesn’t need to be lots of articles; it could be a collection of paragraphs explaining your creative commons licensing, an author bio or a copyright notice. In our example, each article could contain sub-articles or section, as explained above—or both.
Finally, a conclusion!
Jeremy Keith writes that authors are confused about when to use the two elements. I think the name article is a cause of confusion; perhaps post or entry or even story would be more intuitive if you’re thinking about blog or news sites (although not all sites are like that, of course).
But I disagree that the two elements are so similar that they should be amalgamated. Jeremy writes
the only thing that distinguishes the definition of article from the definition of section is the presence of the phrase “self-contained”. A section groups together thematically-related content. An article groups together self-contained thematically-related content. That distinction is too fine to warrant a separate element, in my opinion.
I agree that the difference between them is the “self-contained”ness. But, personally, I find it pretty easy to work out whether something is self-contained or not and have tried to explain it above. Your comments will hopefully let me know if I’ve explained it clearly enough. (I think it’s very tough explaining it in the terse language required in normative sections of a specification).
It seems to me that brand-new elements will require people to spend time learning them without being able to immediately understand the difference in a matching exercise. Dan Cederholm’s Simplequiz showed that in 2003 many of us didn’t understand HTML4 elements properly. How many of us would have chosen ol rather than ul from name and single line from the spec if asked the most appropriate element for breadcrumb trails, or chosen dt as the most appropriate term for the speaker’s name in a dialogue (as the HTML4 spec wrongly specifies)? But seven years down the line, I imagine we all agree that it would have been wrong to amalgamate dl, ul and ol.
I also think the spec isn’t sufficiently clear (and emailed the Working Group): the definition for article says “The article element represents 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 suggests that if you have a self-contained composition that you do not intend to be distributable via syndication, you shouldn’t use article.
Section says “Authors are encouraged to use the article element instead of the section element when it would make sense to syndicate the contents of the element” – here, the intent of syndication is diluted into “it would make sense to syndicate the content”.
I suggest that article be amended to say something similar, eg “The article element represents a self-contained composition in a document, page, application, or site which would make sense if independently distributed or reused, e.g. in syndication.” so that the two mentions of article match.
If we didn’t have an article element, we’d be left with lots of different riffs on section class=article, section class=story or section class=post, which is what HTML5 tries to avoid.
The lucky Mrs Lawson is currently in Thailand visiting her parents, while I stay at home and try to prevent the kids seeing news reports of twenty dead in Bangkok.
The current crop of trouble-makers are the Red Shirts – supporters of ousted and exiled Prime Minister Thaksin Shinawatra. Shinawatra is a deeply unpleasant scumbag businessman turned politico. After his election, a programme of extra-judicial killings of suspected drug-dealers was ordered, with many photos appearing in the press of bodies shot at close range through the back of the head while miraculously resisting arrest while they had their hands and feet tied.
A raid on a mosque in muslim Southern Thailand left 50 prisoners dead after they had been stacked like logs on the back of lorries in the heat for hours. Thaksin said that it was the mens’ fault for weakening themselves through the Ramadan fast.
So there’s nothing to love about Mr Thaksin, except… except… he was elected by a landslide, was the first Thai Prime Minister to serve a full term. He introduced a range of policies that reduced rural poverty by half in four years, the country’s first universal healthcare program, and his re-election in 2005 had the highest voter turnout in Thai history. He was ousted by a military coup while overseas allegedly because of corruption (which he almost certainly was; corruption is epidemic in Thai politics). That’s the trouble with democracy, you see; sometimes, the people vote for idiots or villains.
The group opposing the Red Shirts, the PAD (Yellow Shirts), are the group that shut down Bangkok airport in 2008, causing incalculable damage to the Thai economy during the peak season. They are widely believed to be supported by the Queen and represent the elite of the country—the traditional old guard of aristocracy. Wikipedia sums it up perfectly:
“The Asian Human Rights Commission has noted of the PAD and their agenda that, ‘although they may not describe themselves as fascist, have fascist qualities.’ Citing the claimed failure of popular democracy in Thailand, the PAD has suggested constitutional amendments that would make Parliament a largely royally-appointed body. It has openly called for the military and Thailand’s traditional elite to take a greater role in politics”.
What the whole sorry situation shows is that while Bangkok is a primate city full of millionaires, Porsche cars, skyscrapers and aircon shopping malls, the rural poor in Thailand (most of the people) are as marginalised as ever. The traditional elite pretended a romantic idolisation of the farmers while either ignoring or despising them (much like Russian communists’ relationship with their peasantry), so the poor had to look to a nasty, authoritarian telecoms billionaire to hurl them some cash to buy their votes.
Meanwhile, we hope that my wife makes it safely back home before some idiots shut down the airport again.
Now that the HTML5 spec is settling down, we’re seeing a resurgance of people attempting to cut good bits out. One of the latest targets is the very useful details element. This is an expanding and contracting element that you can use to “hide” more details without JavaScript. It’s not supported anywhere yet, but my glamorous co-author Remy cleverly fakes it on his 2010 Full Frontal conference page. His code is
<details>
<summary>Get in touch</summary>
<p>Interested in sponsoring? Get in touch.</p>
</details>
If you click on the text inside the summary element (which defaults to the text “details” if absent), the details element expands. Click again, and it contracts.
Anyway, the argument against this element is that it duplicates what you can do already with a div, some JavaScript and some WAI-ARIA information to add role and state information to this widget. That’s true, but it completely misses the point that one of the reasons HTML5 is so interesting to developers is precisely because it greatly simplifies web development, meaning you don’t have to muck around with script and ARIA.
The new HTML5 forms UI widgets and validation (supported in Opera), for example, are entirely superfluous, you could argue, because you can do the same in JavaScript. Why have built-in sliders for input type=range or input type=date or even good old fashioned textarea when you could have one single input element and script everything else?
The answer is because it’s much more hassle to pull in script and keep role and state info with ARIA. It’s much better to build these things into the language, with built-in accessibility because the browser vendors bake in role and state information and hook up the widgets to the operating system.
Expecting developers to reinvent this wheel every time is “bolt-on” accessibility, and we all know that they won’t actually do it. Yes, they can use a library. I’ve seen the whole jQuery library pulled in just to make an expando box behave like details.
I refer you to John Foliot, whose email to the HTML Working Group makes an excellent argument that explains the subject much better than I can. I should add that Foliot is by no means an HTML5 cheerleader and is a great advocate of accessibility and ARIA. His main points are
- Elements are better than attributes for semantics, javascript, css
- If something needs to be referenced you should normally make it an element, with an id attribute
- If something represents a separate entity, make it an element: you might want to add attributes later
- having a simple element express something instead of requiring a bunch of lines of scripting is way more efficient.
- moving functionality into the browser natively, instead of relying on scripting which requires additional CPU is an efficient design choice
- having ‘accessibility’ built-in rather than bolt-on (which is what ARIA is) is a fundamental desire of most of us in the a11y community.
I recommend you read the whole email and his blogpost Thoughts on <details> versus @summary .
Added June 2011: Implementing HTML5 <details>.
(Last Updated on 29 June 2011)