[whatwg] "content" element, which we need in our documents

Sun Sep 2 06:05:58 PDT 2012

On Thu, 30 Aug 2012 20:10:15 +0200, Ian Hickson <ian at hixie.ch> wrote:

...
> On Fri, 29 Jun 2012, Cameron Jones wrote:
>>
>> If the content is a special section within the document you should use
>> the <section> element which has semantic meaning over <div>.
>> Alternatively you could use <article> if it's distinct and
>> self-contained. These two elements serve to disambiguate the abstract
>> idea of content into something with semantic meaning which can be
>> instrumented by document consumers.
>
> Indeed, dependong on what exactly you mean by "content" these might be
> more appropriate.

I had believed that the article element would fulfil the requirement. But
the below suggests that my assumption may be incorrect...

> On Fri, 29 Jun 2012, Ian Yang wrote:
>>
>> As described in whatwg specs, a <section>, in this context, is a
>> thematic grouping of content, typically with a heading.
>>
>> As for a <article>, which usually contains its own <header> and
>> <footer>, is used to form an independent content like blog entry,
>> comment, or application.
>>
>> Both section and article elements are not the candidate for containing a
>> website or a blog entry's main content. That obviously is the reason
>> that the example of the nav in HTML5 spec doesn't use them.
>
> The element that contains "a website or a blog entry's main content" is
> <body>, as far as I can tell.

That is technically true, but not useful. The body element also contains a
page's header, footer, general linking buttons (share/like/rate/...),
navigation, advertising, tracking tokens, responses to the content, and
more.

> On Fri, 29 Jun 2012, Aurelio De Rosa wrote:
>>
>> I agree with Ian about the use of <article> and <section>, the
>> specifications are really clear on those elements. The are used to wrap
>> an entire entry, not the "content" (in the meaning Ian stated).
>
> Well, the "content" is what is left after you take out the stuff that
> isn't the "content" (<header>, <footer>, etc).

Yes. If we have elements for all such things, the logical conclusion is
that we don't need one for "the main content". In practice, this also
supposes that authors use those elements.

As far as I can tell, those asking for such an element do not believe we
do have all the other elements, and/or are not convinced they for a
sufficient proportion of cases they are going to be used as designed.

To turn the question around, if it is more convenient for authors to
identify the main content, and not think about the classification of other
parts, should we offer that facility as part of the platform? Or does it
make sense to say that only the exhaustive identification of all
supplementary content is an appropriate way to mark up a page anyway?

>> The read question for me is: What is the problem of having the content
>> at the same level of <header> and <footer> (for example inside an
>> <article>)?
>>
>> Can't we treat everything inside an article which is not in <header> or
>> <footer> is the real "content"?
>
> That's the intent of the spec, right.

In that case I think the spec is wrong. I suspect that real content will
fail to match this intent in a significant proportion of cases. I also
suspect that allowing authors to identify the "main" content would
significantly alleviate the problems caused...

> On Fri, 29 Jun 2012, Ian Yang wrote:
>>
>> By analyzing the example in HTML5 spec, wrapping all content elements
>> can make the structure of the document become more organized. After all,
>> content elements all being at the same level of <header> and <footer> is
>> unreasonable, and sometimes looks messy, especially when there are many
>> different kinds of content elements (p, figure, pre, a, table, ......
>> etc).
>
> I don't understand what the problem is here. How is it "messy"?
>
> If you just want to group some elements together without giving them any
> special meaning, that's what <div> is for.

But that fails to answer the question. It seems obvious that what
advocates of a content element want to do is group some elements together
and give that group a special meaning. I believe that is why div="main",
div="content" and the like are a common paradigm (anecdotally - I have not
done an analysis of any large database).

> On Fri, 29 Jun 2012, Steve Faulkner wrote:
>>
>> ARIA fills the gap in HTML with role="main"
>> http://www.w3.org/TR/wai-aria/roles#main
>
> This role is unnecessary in HTML documents, since browsers can skip the
> non-main content. That's the whole point of elements like <nav>.

Again, that presupposes that all the non-main content is identified.

>> I agree that an explicit element would be nice, but the powers that be
>> have rejected the idea.
>
> It's not clear what the idea is, so it's hard to say that it has been
> rejected. :-)

This makes no sense. You have very clearly rejected the idea of an element
to group the main content, and I am not sure how that is unclear.

> On Sat, 30 Jun 2012, Aaron Gustafson wrote:
>>
>> I’m with Steve here. With so much parity between ARIA and HTML5 with
>> regard to landmarks, it would be nice if we could simplify things with a
>> content/primary/main element.
>
> Could you elaborate on what this element would do and/or mean?

It would act as a grouping construct (a la div, section, or article) for
the "primary content" of a page. It could be used for navigation of a page
by blocks (see the discussions on tabindex scope and navigation cycles and
mechanisms in HTML, and before that in SVG), for indexing content across a
site, for adaptation to different layouts, or whatever else has motivated
the people who have been using a div to identify their main content.

It is more or less impossible to define that exhaustively (since it
depends on the author's judgement of what their main content is), a
working explanation of what it isn't should be sufficient. In case this
element does seem warranted, I would  offer as a starting point

This element identifies the principal content of the page. It is designed
to exclude page components such as site navigation, comments, headers and
footers, and others that are common to a number of different pages.

I'm sure smart people can improve that significantly.

cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
         chaals at yandex-team.ru         Find more at http://yandex.com