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

Wed Nov 14 20:59:56 PST 2012

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

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.

☺

On Wed, Nov 14, 2012 at 9:52 PM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com>wrote:

> On Thu, Nov 15, 2012 at 12:17 PM, Tim Leverett <zzzzbov at gmail.com> wrote:
>
>>
>> > Are you fundamentally distrusting the author in all semantic markup?
>>
>> In some circumstances, yes. Most of the work I've done so far has been in
>> environments where programmers write code, and editors write content.
>> Typically the content is via a CMS. If the editor is good but the
>> programmer is not, the content is still worth having even if its surrounded
>> by rubbish markup. From a data analytics and processing standpoint, there's
>> no reason to discard good content just because its held in bad code in the
>> same way that there's no reason to accept bad content just because its well
>> formatted.
>>
>>
>> > Why then did we introduce <article>, <header>, <nav>, <aside>, <footer>
>> etc when we can't trust the author to put the correct content in there? I
>> don't really see the difference.
>>
>> Steve made a good point about user agents being able to tune into
>> semantic elements for assistive tech. But I would guess (with no data to
>> support my claim) that most programmers *want* to do things the right
>> way.
>
>
> I agree.
>
>
>> I find that, semantically, most of the time most websites are mostly
>> correct. Headings tend to be in <h#> elements, paragraphs tend to be in <p>
>> elements, etc. Heuristic analysis of content can take advantage of semantic
>> markup by giving it a heavier weight than, say...a <div> element, but that
>> doesn't mean the heuristics are any less complex.
>>
>
> Are you saying we should not introduce a <main> element because where
> there is no <main> element we may need to come up with a complex heuristic
> to determine where it should have been?
>
> Silvia.
>
>