Re: main spec updated - changes to parsing and rendering

Hi silvia

On 18 Nov 2012, at 10:20, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:

> On Sun, Nov 18, 2012 at 7:39 PM, Steve Faulkner <faulkner.steve@gmail.com> wrote:
> Hi Silvia,
> 
> >this should be something that every Web page/application provides for.
> 
> It should be something that authors/developers add when the content of the document contains a sub content area that can be logically identified as the main content, distinct from other sub content areas.
> 
> 
> As specified main is not a required element nor is it expected that browsers will add an implied main semantic to every document, which is why there is no requirement to parse every web page as per your example.
> 
> 
> Thanks for the clarification. Let me then put forward the suggestion to change this, because I think if we leave the use of <main> on a voluntary basis, we will likely fail with this element.
> 
What do you consider a fail? I will consider the main element a success if it is used and when it is used it is used correctly in the majority of cases. The data suggests both of these things. 

> I think we should be bold and actually ask to make <main> a required element on Web pages 

part of the reason implementers are not objecting to the main element is that it is a small change implementation wise. What you are suggesting sounds like it is not. 

> - whether author provided or not. This means that in the cases where the author does not provide a <main> element, the browsers have to create one. They can use a good heuristic to position it - such as "before the first <article> element on the page" or "before the first <h1> element on the page" or "after any <menu>, <header> or <aside> element" or all of the above and a bit more. Something we can codify for HTML.

Creating heuristics for to work out  the positions and semantics of blocks of content for many of the existing elements is worth looking into, but I do not see it as necessary or productive to tie it in with the development of the main element.


> I'm saying this because if browser are forced to create a <main> element, every author will see in their inspector where the browser place the <main> element and they can validate and correct it by explicitly creating the <main> element.
> 
> If instead we make it a voluntary element as proposed, authors will see no consequence when they don't have a <main> element. Only accessibility developers will notice the lack of a <main> element and will create one, so the situation will not be any better than with @role=main today: we won't get more sites using it and we won't get better accessible main content on Web pages.
> 

The concept of a main content area is one a generic concept not confined to 'accessibility developers' the data shows this and it is why I have pushed for the introduction of this element. The identification of a content area as 'main content' using an id value is common authoring practice, not just for accessibility purposes and I would say the accessibility purpose is secondary in the majority of instances.

From the data approx >40% of pages identify the main content area using I'd values such as main etc.  The use if role=main is <5%    So there is potential for significant increase in the expression of the semantic through the introduction of an element.

I am not saying that your suggestions are not worth further consideration and note that the implementation of main as currently specced does not prohibit the implementation of your suggestions at a later time.


> If we want to get the general Web authors to become used to writing <main>, it should have a consequence when they don't do it

General web authors already do it using a <div> just as they did and do for header/footer/article etc. 

Regards 

Steve
>