Re: main spec updated - changes to parsing and rendering

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.****
>