[whatwg] New attributes would degrade better than new elements
webmaster at keryx.se
Sun Oct 30 15:05:07 PDT 2011
The main discussions missing from this thread is the actual semantic
meaning of especially <nav>.
First of all, the semantic value should be conveyed to assistive
Before that is happening I'd say it is NOT implemented in any really
usable fashion by browsers. AFAIK some browsers fail this, even though
they are listed as supporting on caniuse.
That being said, I think some browsers, at least Firefox if memory
serves me correctly, do in fact work with screen readers and dropping
the elements in favor of attributes would require some substantial
rework of those browser engines.
However, <nav> is also sectioning content, but <header> and <footer> are
not (2nd point). Making such a distinction based on an attribute sounds
like a recipe for disaster to me.
That being said, AFAIK there is no single browser, server side script,
client side script or other parser known to me that actually honors the
sectioning algorithm in HTML5 completely, so making a spec change now
would not break things up too much.
Thus, nothing is really implemented yet.
Summary: We should not discuss this issue as if it's only a matter of
However, I prefer having elements to attributes for nav, header and
footer. My experience as a teacher is that it is preferable to have a
1:1 mapping between elements and semantic meanings.
That was my main point when arguing that <hgroup> should be dropped. It
alters semantic meaning based on position and that is plain wrong.
Adding semantic meaning using attributes is slightly less wrong, but
Even if IE 7 and 8 will persist for a few more years, HTML5 will affect
the web for decades and there is a limit to how much the future should
be affected by mistakes of the past.
2011-10-26 21:38, Jukka K. Korpela skrev:
> New elements like <nav> and <footer> have the problem that some existing
> user agents don't recognize them, even for the purposes of styling. So
> if you want to use <nav>, then - unless you're using it for purely
> semantic reasons with no idea of styling - you need to use some special
> trick to make old browsers recognize it or assign your styles to some
> logically redundant <div> markup that you use in addition to <nav>.
> Therefore, it would be much simpler, for compatibility with existing
> user agents, to use just <div type=nav> and <div type=footer>. Such
> elements can be styled at will, and if any browsers or search engines
> wish to recognize semantic markup, type=nav should not be a bigger
> problem than <nav>, rather smaller.
> I understand that this should have been suggested years ago. But I
> didn't think of the issue, and it seems that neither did anyone else,
> aloud. And it's not too late, is it?
> Nobody needs new elements with no required functionality, really. The
> idea of more compact markup is pointless. People don't read or write
> markup that much, and if they do, <div type=nav> is no less semantic
> than <nav>. But the latter has the serious drawback of being ignored by
> many relevant user agents.
> It does not need to be the 'type' attribute of course. That attribute
> name is seriously overloaded, so 'kind' might be better. The important
> thing is to introduce an attribute different from 'class', which
> currently lets authors use a free naming space. We don't want to
> interfere with style sheets that might use this or that 'class'
> attribute value; instead, a new attribute name (defined as semantic, not
> presentational, but still useful for styling) is called for - rather
> than new element names, which are born homeless.
Keryx Web (Lars Gunther)
More information about the whatwg