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]

approx
28% 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****
>>
>> * *
>>
>> *Can**Adapt* *Solutions Inc.***
>>
>> *  Adapting the web to all users*
>>
>> *            Including those with disabilities*
>>
>> www.Can-Adapt.com <http://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.****
>>
>
>