W3C home > Mailing lists > Public > public-html@w3.org > February 2013

Re: Context of the main element

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Sat, 2 Feb 2013 23:26:10 +0100
To: Steve Faulkner <faulkner.steve@gmail.com>
Cc: Jeremy Keith <jeremy@adactio.com>, Gez Lemon <g.lemon@webprofession.com>, HTML WG (public-html@w3.org) <public-html@w3.org>
Message-ID: <20130202232610747334.908202a0@xn--mlform-iua.no>
Steve,

per the HTML5 definition, then <main> represents the main content 
section of the body. For contrast, in the WHATWG definition, <main> 
represents its children. And so,  if we have this:

<main><h1>The article X!</h1></main>
       <p>The article continues here.</p>

Then, per HTML5, the <main> would also represent the <p> element. 
Whereas in the WHATWG spec, it would only represent the <h1> element.

I think the WHATWG approach makes more sense as it implies very clearly 
that all the main-content should be wrapped inside the <main> element. 
The HTML5 specification in this aspect seems colored by the ARIA 
specification. ARIA only operates with attributes. Thus could e.g. be 
placed on an empty <img>, since it simply represents a place to jump. 
Since HTML5 introduces an element replacement for the attribute, one 
should take advantage of - and encourage - the advantages of an 
element, namely that it can not only mark the landmark  - where the 
main part begins, but can also show were it ends

Emphasizing that <main> represents its children, could perhaps solve 
the issue of multiple <main> elements as well: If each <main> (except 
the topmost one) is required to be a child of another <main> element, 
then I guess that current ATs will not be confused by it.

Leif H Silli

Steve Faulkner, Sat, 2 Feb 2013 10:29:59 +0000:
> Hi Jeremy,
> 
> 
> "Oh, none. I would imagine that any instances of the main element that
> don't correspond to the main landmark (i.e. any instances that aren't
> scoped to the document body) wouldn't have any special semantics for the
> acc layer …they'd effectively be no different than divs."
> 
> what you appear to be saying is that structural elements such as
> header/footer if not scoped to the body should have a presentational role
> only. I don't think its that simple.
> 
> The vast majority elements and attributes have some sort of mapping to the
> accessibility layer.
> 
> ARIA is not used in the mapping of  the vast majority of roles,states and
> properties , representations of them are exposed in the accessibility APIs
> in cases where  no roles, states and properties native to the API's are
> defined.
> 
> 
> 
> regards
> SteveF
> 
> On 1 February 2013 11:20, Jeremy Keith <jeremy@adactio.com> wrote:
> 
>> Steve wrote:
>>> for example I don't see how your suggested changes will benefit users
>> who consume the semantics, what will the semantics of nested main be when
>> mapped to the acc layer?
>> 
>> Oh, none. I would imagine that any instances of the main element that
>> don't correspond to the main landmark (i.e. any instances that aren't
>> scoped to the document body) wouldn't have any special semantics for the
>> acc layer …they'd effectively be no different than divs.
>> 
>> And that prompts the question "well, why not just use a div, then?" …which
>> is a fair question. But seeing as HTML5 introduces a few other new elements
>> that (I believe) don't have any effect on the outline or on the acc layer
>> (e.g. header and footer within sectioning content), then the introduction
>> of a new element like main seems like a good opportunity to give authors
>> the option of using a dedicated element in place of a generic div.
>> 
>> Cameron referred to this as "semantic sugar", which, while it was probably
>> meant as a negative term, is actually a pretty good way of describe many of
>> the new elements in HTML5.
>> 
>> So my suggestion really just boils down to throwing a bone to authors.
>> 
>> As for use cases: every single use of a header or footer within sectioning
>> content (other than the body element) is also a potential use case 
>> for main.
>> 
>> Jeremy
Received on Saturday, 2 February 2013 22:26:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:37 UTC