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

Hi Steve and all other chief editors,

Thanks for drafting that.

Comparing to the "complementary" element, maybe we could simply call this
new element "main". What's your thought?

And could we make it a sectioning element instead of a flow content? The
document outline can become more clearer if the main content element is a
sectioning element. Please refer to a previous topic "Document outline and
the wrapper of the main content" (
http://lists.w3.org/Archives/Public/w3c-wai-ig/2012JulSep/0157.html )


Kind Regards,
Ian Yang

On Mon, Sep 10, 2012 at 4:02 AM, Steve Faulkner <faulkner.steve@gmail.com>wrote:

> 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 23:11:21 UTC