- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 21 Feb 2008 20:08:01 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 21 February 2008 12:08:01 UTC