Re: [whatwg] A plea to Hixie to adopt <main>

Hi Tim,


> Are you saying we should not introduce a <main> element...
>
> I don't believe I ever said anything about not introducing a
> <main>element. I'm very much on the fence about it. I've been trying
> to carefully
> balance the pros and cons to avoid a biased judgement. Here are some of
> what I've come up with.
>
> Pro: Adding a <main> element will provide a semantic element that
> developers can use to indicate primary content of a document.
> Con: Adding a <main> element adds redundancy to the [role="main"]
> attribute.
>

I don't see why this is a con, if main is mapped to role=main in the
browser it means that authors won't have to. Also adding
aside/article/footer etc adds redundancy to the matching ARIA roles.




> Pro: Adding a <main> element will allow developers to use a format such as:
> <body>
>   <header />
>   <main />
>   <footer />
> </body>
> which tends to be quite clean and understandable (the easier it is to read
> code, the easier it is to fix code).
> Con: Implementing the <main> element in a backwards compatible manner
> requires JavaScript.
>

it is/was the same for any of the new structural elements.


> Pro: Assistive technologies can use the <main> element as a means to
> rapidly navigate to the primary content.
> Con: The <main> element can only be used once per page. Pages with multiple
> content areas, or fragmented content would need to pick a single content
> region as primary, or not use the element. This restriction will likely
> cause more confusion than if multiple <main> elements were allowed.
>

>From the data it does not appear that authors are confused about use of
role=main or the use of semantic id values to designate the main content
area.

Authors do not appear to have an issue with marking up <div id="main"> and
using it once per page.  I think that the restrictions make it easier to
use and understand rather than harder.


> Pro: The <main> element can only be used once per page. This forces the
> author to decide exactly where the main focus of the page lies, rather than
> relying on assumptions.
> Con: The <main> element is supposed to exclude content that is repetitious
> across pages, but content is often interspersed with blocks of
> advertisements, modules, CTAs and the like.


authors can use more granular elements within the <main> element, to
structure content, example:

<main>
<article/>
<aside> advertisements</aside>
<article/>
</main>

can you provide some examples of the sort of pages you are talking about?
It would be useful.


>
> Personally, I'd rather see <main> be more about marking up content in
> general, such as in this example which is invalid given the current state
> of the spec:
> <article id=1>
>   <header />
>   <main />
>   <footer />
> </article>
> <article id=2>
>   <header />
>   <main />
>   <footer />
> </article>
>
> ...although this would probably fit better as a <content> element, and
> would require a whole other line of discussion that can wait for another
> day.
>

Indeed, this appears to be something different from what the <main> element
is designed for.


Regards
SteveF

Received on Thursday, 15 November 2012 10:31:57 UTC