Re: Context of the main element

Good point.

On 31 January 2013 16:24, Jeremy Keith <jeremy@adactio.com> wrote:

> Hi all,
>
> I have a question about the context of the newly-landed main element (so
> probably a question for Steve then).
>
>
> http://www.w3.org/html/wg/drafts/html/master/grouping-content.html#the-main-element
>
> I'm curious as to why its use is specifically restricted to the body
> element rather than any kind of sectioning content.
>
> ""Authors must not include more than one main element in a document."
>
> I get the rationale behind the main element: it plugs a gap in the overlap
> between native semantics and ARIA roles (namely role="main"). But if you
> look at the other elements that map to ARIA roles (header, footer, nav),
> those elements can be used multiple times in a single document by being
> scoped to their sectioning content ancestor.
>
> Let's say, for example, that I have a document like this, containing two
> header elements:
>
> <body>
>  <header>Page header</header>
>  Page main content starts here
>  <section>
>   <header>Section header</header>
>   Section main content
>  </section>
>  Page main content finishes here
> </body>
>
> ...only the first header element (the one that's scoped to the body
> element) will correspond to role="banner", right?
>
> Similarly, in this example, only the final footer element will correspond
> to role="contentinfo":
>
> <body>
>  <header>Page header</header>
>  Page main content starts here
>  <section>
>   <header>Section header</header>
>   Section main content
>   <footer>Section footer</footer>
>  </section>
>  Page main content finishes here
>  <footer>Page footer</footer>
> </body>
>
> So what I don't understand is why we can't have the main element work the
> same way i.e. scope it to its sectioning content ancestor so that only the
> main element that is scoped to the body element will correspond to
> role="main":
>
> <body>
>  <header>Page header</header>
>  <main>
>   Page main content starts here
>   <section>
>    <header>Section header</header>
>    <main>Section main content</main>
>    <footer>Section footer</footer>
>   </section>
>   Page main content finishes here
>  </main>
>  <footer>Page footer</footer>
> </body>
>
> Here are the corresponding ARIA roles:
>
> <body>
>  <header>Page header</header> <!-- role="banner" -->
>  <main>Page main content</main> <!-- role="main" -->
>  <footer>Page footer</footer> <!-- role="contentinfo" -->
> </body>
>
> Why not allow the main element to exist within sectioning content
> (section, article, nav, aside) the same as header and footer?
>
> <section>
>  <header>Section header</header> <!-- no corresponding role -->
>  <main>Section main content</main> <!-- no corresponding role -->
>  <footer>Section footer</footer> <!-- no corresponding role -->
> </section>
>
> Deciding how to treat the main element would then be the same as header
> and footer. Here's what the spec says about the scope of footers:
>
> "When the nearest ancestor sectioning content or sectioning root element
> is the body element, then it applies to the whole page."
>
> I could easily imagine the same principle being applied to the main
> element. From an implementation viewpoint, this is already what browsers
> have to do with header and footer. Wouldn't it be just as simple to apply
> the same parsing rule to the main element?
>
> It seems a shame to introduce a new element that can only be used zero or
> one time in a document ...I think the head and body elements are the only
> other elements with this restriction (and I believe the title element is
> the only element that is used precisely once per document).
>
> It would be handy to be able to explicitly mark up the main content of an
> article or an aside—for exactly the same reasons that it would be useful to
> mark up the main content of a document.
>
> So why not?
>
> --
> Jeremy Keith
>
> a d a c t i o
>
> http://adactio.com/
>
>
>
>


-- 
ian devlin
e: ian@iandevlin.com
w: www.iandevlin.com
t: @iandevlin <http://www.twitter.com/iandevlin>
skype: idevlin

buy my book: html5 multimedia: develop and design<http://html5multimedia.com>

Received on Thursday, 31 January 2013 15:52:22 UTC