[whatwg] article: do we really need this?

[Ian Hickson]

Executive summary: no change to the spec has been made.

On Mon, 5 Mar 2007, Elliotte Harold wrote:
>
> Has there been any extensive discussion of the article element in Web 
> Apps 1.0? It is currently described as:
> 
> "represents a section of a page that consists of a composition that 
> forms an independent part of a document, page, or site. This could be a 
> forum post, a magazine or newspaper article, a Web log entry, a 
> user-submitted comment, or any other independent item of content."
> 
> It seems sort of wishy washy. Most of the time what I think of as an 
> "article" is a separate page with its own URL. This use case seems to be 
> handled better by section, perhaps with a role attribute. Maybe a 
> section is less independent than an article, but that's going to be a 
> very fuzzy distinction, and really hard to explain, teach, and validate.
> 
> Is there some obvious use case for this element? Mostly to me it just 
> seems to needlessly clutter the spec, especially once you consider how 
> it relates to potential sibling sections. I think I'd prefer to just 
> drop it and stick with section.
> 
> Anyone else feel the same or am I crying in the wilderness again? :-)

I think there is a clear distinction between a section (something that is 
part of a larger work) and an independent article (e.g. blog post, blog 
comment, etc). Indeed I think the distinction already exists on the Web, 
e.g. <article> elements correspond pretty well to what people give 
permalinks to, and <section> elements don't.


On Tue, 6 Mar 2007, fantasai wrote:
> 
> This element would be extremely useful to someone with a screen reader. 
> It would create an implied UA hook for "skip to main content", for one. 
> With multiple postings within a page, it would create a reliable way of 
> "skimming" the main sections (by reading the first bit of content on 
> each posting), even when there are no headers or when the postings 
> themselves have internal sectioning and headers (especially if those are 
> inconsistent).
> 
> For printing, the <article> element would make it easy to cut out 
> extraneous content and print just the main content of a web page.

Right, the main likely use of the element is as a styling hook.


On Tue, 6 Mar 2007, Alexey Feldgendler wrote:
> 
> It just occurred to me: because of this particular possibility, it's 
> probable that <article> either won't be used or will be abused so that 
> advertisements are put inside <article> instead of being left outside. 
> Otherwise it will be too easy for a user to hide all ads (e.g. with a 
> toggle button).

Yes, I expect ads to be inside <article> elements.


> BTW, there's no easy way in today's CSS to hide everything except 
> <article>.

body > * { display: none; }
body > article { display: block; }


On Tue, 6 Mar 2007, Elliotte Harold wrote:
> > 
> > This element would be extremely useful to someone with a screen 
> > reader. It would create an implied UA hook for "skip to main content", 
> > for one. With multiple postings within a page, it would create a 
> > reliable way of "skimming" the main sections (by reading the first bit 
> > of content on each posting), even when there are no headers or when 
> > the postings themselves have internal sectioning and headers 
> > (especially if those are inconsistent).
> 
> But how would it do this when <section> or <section role='article'> 
> would not? If the authors can't make the internal sectioning consistent, 
> do you expect them to make the internal "articling" consistent?

What's the difference between <section role=article> and <article>, other 
than the level of complexity?


On Wed, 7 Mar 2007, Matthew Raymond wrote:
> 
>    I find that anything I use that resembles the semantics of an 
> <article> usually has a class name attached to it for styling purposes, 
> especially in relation to fixed headers, footers and navigational bars, 
> so <section> alone wouldn't do.
> 
>    Would <section role="article"> do? Well, first of all, what would it 
> do that a predefined class name wouldn't, since from a markup point of 
> view, the only difference is the name of the attribute? Namespaces? 
> Nope, in XHTML you have to use |xmlns| to define those, so implementing 
> |role| with namespaces means creating a namespacing standard for HTML. 
> Good luck on that.
> 
>    Are semantics the difference? Well, |role| was designed to be purely 
> semantic. However, when you're styling an element, are you seriously 
> going to include a |class| on each element with a particular role, or 
> are you going to use selectors to style all elements with that |role|? 
> In the latter scenario, the selector may be just slightly more 
> complicated, but you only need to write it once and you save on markup. 
> Therefore, roles end up being functionally the same as predefined class 
> names, with the only difference being the entirely theoretical purity of 
> their semantics.
> 
>    Let's say, however, that we prefer |role| to |class| anyway. Why 
> would we want to do <section role="article"> when <article> is shorter:
> 
> | <section role="article"></section>
> | <article></article>
> 
>    And you can't argue fallback, because <section> and <article> are 
> being defined in the same spec.
> 
>    What's more is that an article is more important semantically than a 
> section, and articles (marked up or not) actually occur with more 
> frequency, so why would we want to demote it two levels in markup?
> 
>    "What demotion?", you might ask. The first level of demotion is to 
> make it an attribute:
> 
> | <section article></section>
> 
>    This, however, would annoy the XHTML folk who can't use attribute 
> minimization, so it's demoted once again to a mere attribute value:
> 
> | <section role="article"></section>
> 
>    Part of the problem with this kind of markup demotion is that new 
> attributes that would have gone on an <article> suddenly need to apply 
> globally to every element, which is cumbersome. (Think <li rel=""> 
> without the |href| attribute and you only begin to understand.) Another 
> problem is that the more roles that apply to specific elements like 
> <section>, the more broad the semantics of the element have to be to 
> accommodate all these roles. In other words, global attribute values 
> broaden the semantics of elements rather than making them more specific, 
> and thus water them down until they loose their specificity. In the case 
> of <section>, it could eventually become the semantic equivalent of a 
> <div> with better heading support.

I agree with the above.


>    Now, consider what would happen if you made it so that <section> 
> could only be contained in an <article>. That makes all <section> 
> elements sections of an article and reinforces the concept that 
> <article> represents the primary element for content.

This would be possible, but I don't think we really want to go there. For 
example, I would imagine <section>s in a <body> would be quite common.


On Wed, 7 Mar 2007, Elliotte Harold wrote:
> 
> It's not really a question of whether article makes sense. The question 
> is whether it makes *enough* sense. There are arguments for it, but 
> they're very weak. I do not see a community crying out for this.

They aren't crying out for <section> either, they're happy using <div> 
and classes. :-) But that doesn't mean we shouldn't try to improve 
matters. The response to these new elements has been quite positive.


> I don't think it's going to help anybody all that much, and I'm afraid 
> it's going to end up like address: a poorly understood, rarely used 
> element that's misused more often than it's used properly.

I'm not convinced the data backs up your claim regarding <address>.


> I suspect I could ask the same question of a few other elements as well. 
> time and meter come to mind. They at least don't have any obvious 
> equivalents already in the spec, and are obvious enough they perhaps 
> won't be frequently misused; but do authors actually need these? Will 
> they use them?

Simplifying a bit:

<meter> is primarily there to prevent people from abusing <progress>. 
<time> is there to prevent the Microformats crowd from abusing <abbr>.


On Wed, 7 Mar 2007, Matthew Raymond wrote:
> 
>    Well, I for one have use <div class="content"> for essentially the 
> same thing all the time, so it'd be nice to have for me at least.

...and indeed such class values are very common.


On Wed, 7 Mar 2007, Adrian Sutton wrote:
> 
> One way this could be used quite powerfully is for inline editing. This 
> would only work if there were a globally unique ID for the article 
> included (an URL to that specific article would make most sense). It 
> would then be fairly trivial to provide an edit mechanism (via 
> JavaScript or built into the user-agent) that opened an editor 
> specifically for that article and could send it back to the server with 
> the appropriate unique ID so the server knew which article to update.
> 
> Such behaviour is already present in a lot of scenarios - blogs tend to 
> provide an Edit link for users with edit permissions for specific posts 
> or comments, wikis do similar things and more and more CMS systems are 
> investigating or adding in-place editing.
> 
> It's possible to use the section element for this but its description 
> doesn't seem as well suited - it focuses more on specific areas of the 
> rendered page rather than different sources of content that have been 
> combined.

Agreed.


On Tue, 6 Mar 2007, Benjamin Hawkes-Lewis wrote:
>
> The HyperTextuality Firefox extension I've been writing attempts to work 
> out the most relevant URI for a given piece of content, for bookmarking 
> or quoting. Front pages of blogs, the most important use-case, also pose 
> a particular problem as many blogs don't have an obvious structure (to 
> an automated agent) to distinguish individual articles with a permanent 
> link from the main body of the text (annoyingly, this seems especially 
> true of extremely popular blogs using Moveable Type). <article> sounds 
> like it would bring somewhat more consistency to that situation.
> 
> There is a problem in that <article> might still have no way of 
> referencing it, but the fact that is a discrete piece of content 
> suggests it should. Could include a conformance requirement for 
> <article> to have a fragment identifier (e.g. for comments) and/or a 
> permalink (e.g. for blog posts)? e.g.:
> 
> <article> ... <a 
> rel="permalink">http://www.example.com/articles/2458</a> .... </article>
> 
> or
> 
> <article id="article-2458-comment-358686"> ... </article>

I don't think we want to require it, but both (with rel=bookmark) are 
already possible and are defined as good signs that that's the link you 
want.


> I'm not sure about the use of <address> for author information: what 
> happens with anonymous comments, for instance? It might be nice if the 
> spec could define authorship as inherited from parent elements if author 
> is not specified, but we'd need to specify how to mark up an <article> 
> as anonymous first. <address>Anonymous</address> isn't a simple 
> solution, since given multiple languages, synonyms, and 
> euphemisms/jokes, that would be automated agent's nightmare.

Does the spec work for this at the moment?


On Tue, 6 Mar 2007, Elliotte Harold wrote:
> 
> The use cases that are being suggested are real use cases, but they seem 
> to be well solved by a section element, probably with some predefined 
> roles.
> 
> I don't think the nature of an <article> is likely to be obvious to most 
> authors. I don't have a lot of optimism that it will be used in the way 
> it's intended, if it's used at all.

I think it is likely blog templates will use it correctly most of the 
time, which would cover many uses of this element. I think the use cases 
for <section> and <article> are quite distinct, and that trying to merge 
them would hurt both elements on the long run.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'