- From: Tim Leverett <zzzzbov@gmail.com>
- Date: Wed, 14 Nov 2012 23:59:56 -0500
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: whatwg <whatwg@whatwg.org>, "Jens O. Meiert" <jens@meiert.com>
> 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@gmail.com>wrote: > On Thu, Nov 15, 2012 at 12:17 PM, Tim Leverett <zzzzbov@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. > >
Received on Thursday, 15 November 2012 05:00:59 UTC