[webkit-dev] Adding <main> element to WebCore

Wed Nov 28 00:43:04 PST 2012

Summarizing my comments from some of the standards mailing list threads on this:

(1) I think the <main> element on the whole is marginally but not hugely beneficial on net. To some extent this is a matter of opinion though. Marking only non-main things seems suitable for a fallback heuristic, but does not seem great as the primary way to identify the main content. role=main can achieve this, but sectioning elements take care of the other landmark roles, and it seems strange to have this be the odd one out. In my own judgment, this outweighs risk of misuse. On the other hand, this element does not add material functionality over what <section role=main> or <div role=main> would do, so the benefit is fairly small, compared to an element that does something authors couldn't do otherwise.

(2) The implementation cost is pretty low, so the main consideration is whether this would benefit the Web.

(3) Although I mildly favor this element, I would only want to add it to WebKit if there is community consensus to do so. I would certainly not fight to the death for it.

(4) I think a relevant consideration is whether other browser vendors are interested in adding support. Some folks representing other implementors have expressed personal interest, but nothing on the "we're doing it" level.

Regards,
Maciej

On Nov 27, 2012, at 8:33 PM, Steve Faulkner <faulkner.steve at gmail.com> wrote:

> 
> On Wed, 28 Nov 2012, ian hickson wrote:
>  
>  
> ARIA is used by very few authors, and those authors are, by and large,
> much more competent than average. ARIA therefore tends to be used to a
> much higher level of quality than most elements.
> 
> The claim that developers that use ARIA are much more competent than average is unsubstantiated.
> a quick check (html conformance) of some data [1] does not indicate any difference in the competency of developers that use ARIA and those who do not.
> 
> ARIA like HTML contains simple well understood features (such as role=main) and more complex features more prone to errors of use (such as aria-posinset)
> 
> Where features are well understood, map on to common authoring concepts and easy to author they are often used correctly.
>  
> It would probably be used about as well, maybe a little less well than
> them because the idea of what is "main" varies from author to author (e.g.
> in the sites you analysed on the WHATWG list, as well as in many that
> others have mentioned before, id="main" and id="content" often include
> things like some navigation, some headers, some sidebars, some footers).
> 
> The data  does not support the claim that "id="main" and id="content" often include
> things like some navigation, some headers, some sidebars, some footers)." It indicates that in approximately 80% of cases headers, footers, navigation etc are not included. 
> 
>  
> 
> > so I don't see why they would make sense to be supported while <main>
> > doesn't.
> The use case for e.g. <header> is mainly one of maintenance and styling:
> lots of people style their headers very specifically. In general it
> doesn't matter if one author marks his navigation as being part of his
> header and another marks his navigation using <nav>; the result is the
> same: they are clearly marked in the source, they can be styled, and they
> can be skipped. If one author doesn't use it, or even if most authors use
> it incorrectly, it doesn't mean that other authors can't use it.
> The use case for <main> is accessibility navigation. If authors use it
> incorrectly, the feature *doesn't work*. The element becomes pointless.
> Combined with the way that the concept of "main" varies from author to
> author, you dramatically increase the likelihood that the element won't
> satisfy its stated purpose.
> 
> From analysing the data [2] the wrapping of main content area of a web page in a div with an id value that indicates it is the 'main content' is a common occurrence, this indicates that developers do this for reasons other than accessibility as the majority do not include role=main or use the div as a target for a skip link. What the main element does is piggyback accessibility onto a common authoring practise.
>  
> Also, since few authors ever test how their
> page works in ATs, they won't know that there's a problem.
> 
> this is a problem, and it has begun to reveal itself due the misuse of new elements such as <section> and <article>. the difference between <main> and some of the other new elements is it is a simpler concept and is unambiguously defined. It builds on the singular instance of use per page (id value) rather than class names.
>  
> This is like the difference between <a href=""> and <img longdesc="">. If
> many authors don't use <a href=""> right, big deal; their pages don't work
> well, but it doesn't stop other authors from using it. If many authors use
> longdesc="" incorrectly, however, it means users who try to use the
> feature quickly stop expecting it to work and they give up and even pages
> that use it correctly lose out.
> 
> drawing a comparison between longdesc and main here is fallacious: 
> longdesc is known to be used incorrectly much of the time while role=main is known to be used correctly much of the time.
> <div id=main> is known to be used correctly much of the time.
> longdesc is bolt on accessibility requiring not only the correct use of the attribute, but also the provision of extra authored content that the attribute points to (i.e a lot of extra effort)
>  <main> is built in accessibility that sneaks accessibility in on the back of a common authoring practise,i.e reduction of effort, much like the <nav> element
>  
> And, since few authors ever test how their
> page works in ATs, they don't know that there's a problem, and so the
> feature is _more_ likely to be broken than <a href="">.
> 
>  that's why building accessibility into features that are based on common authoring practises is a good thing.
> 
> 
> [1] http://www.html5accessibility.com/tests/HTML5-main-content/
> [2] http://lists.w3.org/Archives/Public/public-html/2012Oct/0109.html
> 
> -- 
> with regards
> 
> Steve Faulkner
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121128/2978791b/attachment.html>