W3C home > Mailing lists > Public > public-html@w3.org > December 2012

Re: Technical concerns about the addition of <main> to HTML

From: Henri Sivonen <hsivonen@iki.fi>
Date: Tue, 11 Dec 2012 13:44:48 +0200
Message-ID: <CAJQvAudaXvO4m+bpYoiJ0ZfCUTpJrjf75oTPoj3=a19DOr7JXQ@mail.gmail.com>
To: Steve Faulkner <faulkner.steve@gmail.com>
Cc: HTMLWG WG <public-html@w3.org>, David Baron <dbaron@dbaron.org>
On Wed, Dec 5, 2012 at 11:51 AM, Steve Faulkner
<faulkner.steve@gmail.com> wrote:
> It would be super useful  if any implementers with technical concerns
> provided them publicly on this list

I don’t have any concerns that should be considered blockers for
implementing <main>.

I do have one concern, but it shouldn’t block <main>, since my concern
applies to role=main, too: When there are multiple elements whose role
is main (given either by <main> or role=main), what’s the processing
model? It appears that the current de facto processing model is to
present all “main” landmarks in a landmark list, but that presupposes
a UI design: that there is a landmark list. The processing model where
all “main” landmarks count wouldn’t make as much sense for a UI that
provides a keyboard shortcut for moving focus to main content for
users who can see but navigate without a pointing device. I think I’d
be slightly less concerned if only the first element with the role
main was exposed as having the role main exposed to UI, but I could be
convinced otherwise. Mainly, I’d like the processing model to be
written down somewhere. (Maybe it already is.)

But as mentioned above, since this concern applies to role=main
already, this concern should not block <main>, since <main> neither
addresses my concern nor makes my concern worse.

On Thu, Dec 6, 2012 at 11:15 AM, L. David Baron <dbaron@dbaron.org> wrote:
> I also think there ought to be a high bar to adding new semantic
> elements to HTML.  This is not because of the cost of
> implementation; that's low.

Indeed, <main> should be very easy to implement. AFAICT, there are
three things to do: parser change, UA stylesheet change and
accessibility mapping change. I know the parser and UA stylesheet
changes are trivial. The accessibility mapping change looks trivial to
me in Gecko, but I’m not sure if I’m missing something.

Writing unit tests would take more effort, of course.

> It's because it increases the cost of
> teaching good HTML authoring practices.  We ought to avoid leaving
> students of HTML to puzzle over questions of the form "When do I use
> element A vs. B?" unless we have a good reason to do so.  (For
> example, when do I use <main> vs. use the other approaches in
> http://dev.w3.org/html5/spec/links.html#the-main-part-of-the-content ,
> or both, or neither?)

The <section> vs. <article> teaching problem already exists. I think
it would be unfortunate not to have <main> because of a teachability
conflict with <article>. If we wanted to fix teachability conflicts,
the most effective fix would probably be
obsoleting/deprecating/downplaying <article> rather than avoiding
<main>.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Tuesday, 11 December 2012 11:45:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:36 UTC