[whatwg] New attributes would degrade better than new elements

Hello all

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

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

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

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)
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/

Received on Sunday, 30 October 2011 15:05:07 UTC