W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2012

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

From: Eitan Adler <lists@eitanadler.com>
Date: Thu, 15 Nov 2012 20:21:03 -0500
Message-ID: <CAF6rxg=2Wh6VQtmbGqc0BWzctuXSK6hbmNcc2vRzd5eSSTMuvw@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: whatwg <whatwg@whatwg.org>, Ian Yang <ian@invigoreight.com>, Tim Leverett <zzzzbov@gmail.com>
On 15 November 2012 19:20, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
> On Fri, Nov 16, 2012 at 1:45 AM, Tim Leverett <zzzzbov@gmail.com> wrote:
>
>> >> 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.
>>
>> Redundancy tends to be a source of error if they get out of sync. If one
>> browser supports [role="main"] and another supports <main>, both would be
>> needed to provide compatibility. Obviously this is a bit contrived, as
>> browsers supporting <main> would likely also support [role="main"], but
>> older versions would not support <main> . Going forward, this would mean
>> that authors wanting to use <main> would have to use <main role="main"> for
>> backwards compatibility.
>>
>
>
> Actually, there's a good point: I would actually add this: if <main> or an
> element with @role="main" exist on the page, there is no need to run the
> Scooby-Doo algorithm and that element can just be chosen as the <main>
> element.

What if both exist but are different elements?


-- 
Eitan Adler
Received on Friday, 16 November 2012 01:45:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:11 GMT