Re: main spec updated - changes to parsing and rendering

On Mon, 19 Nov 2012 19:42:04 +0100, Léonie Watson <tink@tink.co.uk> wrote:

>
> Steve Faulkner wrote:
>
> “>I'd like to see <main> being more useful than just to replace "<div  
> id=”main”>", but if this is agreeable as a use case by browsers, then I  
> >guess we can just >get the experience for now and make corrections  
> later as we see what authors do with it.
>
> So would I, which is why I have included text to encourage browsers to  
> provide built in keyboard navigation to the main element. Your  
> >suggestions would be another step. I think we are more likely to get  
> additional usefulness via incremental additions/modifications.”
>
>
> I wonder whether making main a required element would encourage AT  
> vendors to build functionality around it? I’m thinking of >integrated  
> skip link replacement, rather than functionality that includes main as  
> one of the set of navigable landmarks.

I have only thought about this for a couple of minutes, but I don't think  
it would make a lot of difference.

If browsers actually decide to do this, it would suggest that there is  
real value and that there are no real compatibility issues. But I'm not  
convinced that browsers do a good enough job at picking this to enforce  
the creation of a dummy DOM element (the TBODY case is much much  
easier...), and I am with Steve that success doesn't have to be getting it  
perfect, just getting net improvement.

cheers

Chaals

>
> Léonie.
>
> From: Steve Faulkner [mailto:faulkner.steve@gmail.com]Sent: 19 November  
> 2012 10:32
> To: Silvia Pfeiffer
> Cc: David MacDonald; HTML Accessibility Task Force
> Subject: Re: main spec updated - changes to parsing and rendering
>
>
> Hi Silvia,
>> 'd like to see <main> being more useful than just to replace "<div  
>> id=”main”>", but if this is agreeable as a use case by browsers, then I  
>> >guess we can just >get the experience for now and make corrections  
>> later as we see what authors do with it.
>
> So would I, which is why I have included text to encourage browsers to  
> provide built in keyboard navigation to the main element. Your  
> >suggestions would be another step. I think we are more likely to get  
> additonal usefulness via incremental additions/modifications.
>
>
>> I fear, however, that with this as the sole purpose it will go the same  
>> way that <article> or <aside> has been going, namely not much >uptake  
>> since >existing markup patterns satisfy the use case and there is no  
>> perceivable win by using <article> or <aside>.
>
> I think it is too early to say whether most of the other elements have  
> been successful or not, implementations are not complete and uptake >is  
> an ongoing process.
> I also think that the main element has more chance of being successful  
> as its utility does not rely upon the presence of the other elements  
> >and getting authors to add one element for accessibility reasons is  
> easier than asking them to add a many. Furthermore the meaning of and  
> >use of the main element is easier to grasp than some of the other  
> elements, which do confound authors in regards to when and how to use  
> >them.
>
> data points:
> of the 1440 (HTML5) page sample of the top 10, 000 web sites[1]
>
> approx28% use nav
> 16% use article
> 31% use header
> 28% use footer
> 13% use aside
> 24% use section
>
>
>
> [1]  
> http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-data-for-the-masses/
>
> best regards
> Steve
>
> On 19 November 2012 07:54, Silvia Pfeiffer <silviapfeiffer1@gmail.com>  
> wrote:
>
> I'd like to see <main> being more useful than just to replace "<div  
> id=”main”>", but if this is agreeable as a use case by browsers, then I  
> >guess we can just get the experience for now and make corrections later  
> as we see what authors do with it.
>
> I fear, however, that with this as the sole purpose it will go the same  
> way that <article> or <aside> has been going, namely not much uptake  
> >since existing markup patterns satisfy the use case and there is no  
> perceivable win by using <article> or <aside>.
>
> Regards,
> Silvia.
>
>
> On Mon, Nov 19, 2012 at 3:54 AM, David MacDonald <david100@sympatico.ca>  
> wrote:
>
> I don’t think we should be heavy handed about it.
>
>
> I think authors will be happy not to have to do <div id=”main”> which is  
> what I see a lot of. I believe that a slideshare from Patrick Lauke >had  
> id= “main” as the 12th most popular class on the web...
>
>
> We have <nav><article> etc... let’s recommend it as a missing element in  
> HTML5 in the same category as..
>
>
> Cheers
>
> David MacDonald
>
>
> CanAdapt Solutions Inc.
>
>  Adapting the web to all users
>
>            Including those with disabilities
>
> www.Can-Adapt.com
>
>
> From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com]Sent:  
> November-18-12 5:20 AM
> To: Steve Faulkner
> Cc: HTML Accessibility Task Force
> Subject: Re: main spec updated - changes to parsing and rendering
>
>
> 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.
>
> I think we should be bold and actually ask to make <main> a required  
> element on Web pages - 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.
>
> 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.
>
> 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.
>
> Regards,
> Silvia.
>
>
>



-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
chaals@yandex-team.ru Find more at http://yandex.com