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

Hi Chaals,

thanks for you counterpoints

I have taken a stab at drafting a definition of a maincontent element:
http://www.html5accessibility.com/tests/maincontent.html

any feedback welcome!

regards
Stevef


> Message: 7
> Date: Sun, 02 Sep 2012 15:05:58 +0200
> From: "Charles McCathie Nevile" <chaals@yandex-team.ru>
> To: whatwg <whatwg@whatwg.org>
> Subject: Re: [whatwg] "content" element, which we need in our
>         documents
> Message-ID: <op.wj0en8gmy3oazb@chaals.local>
> Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
>
> On Thu, 30 Aug 2012 20:10:15 +0200, Ian Hickson <ian@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@yandex-team.ru         Find more at http://yandex.com
>
>
> ------------------------------

Received on Sunday, 9 September 2012 20:04:07 UTC