[whatwg] New attributes would degrade better than new elements

[Jukka K. Korpela]

27.10.2011 5:38, Eric Sh. wrote:

> And if we stop adding new features old browsers do not support or not use
> them because very little browsers are not supporting them then it would
> completely stop innovation and the evolution of the web.

How does this relate to the question of adding element vs. adding 
attributes?

> I am supporting what Ashley has said, just think about it if you sorround
> context with <article>  then speech browsers can know from where to start
> reading the article instead of a whole web page.

They could do just the same with <div type=article>.

> I believe that the decision makers are not stupid,

_I_ am not stupid, and I did not come to think of this earlier.

> they are smart enough to
> know all these technical issues and conflicts

There are issues and conflicts with adding a new element like <nav>, as 
compared with adding a new attribute. So the question is: what do you 
gain by adding an element rather than an attribute?

There is no _required_ functionality or default rendering for <nav> or 
<article> and no special attributes for them. What you lose by having 
them as elements rather than attributes is that you cannot style them in 
a manner that works on all browsers.

> And lastly, I understand and encourage different opinions but I think it is
> too late to change anything that has been already implemented by all major
> browsers(Including IE 9!)

Do you think that older versions of IE can be ignored? They will be with 
us for years. There are ways to "teach" new elements to them, but they 
are based on JavaScript (so they do not work universally). Such issues 
would be quite unnecessary if attributes were used and not elements.

There's no implementation worth mentioning so far, or can you mention a 
single browser or search engine that actually does something useful 
with, say, <article>? Don't you think it would be triviality to its 
authors to extend the feature to cover <div type=article>?

The only real argument in favor of elements is brevity, and it should 
not weigh much when compared with compatibility issues.

This is also a matter of future additions. When new markup features will 
be added, will they be designed to degrade gracefully and to allow 
smooth transition? If, for example, it will be decided that dedicated 
markup for the main content of a document is needed after all, adding a 
new element like <main>...</main> would have the same problems as <nav>, 
<article>, etc. now have. It would be much smoother to introduce <div 
type=main>...</div>, and taking the new feature into use in old 
documents would require just the addition of one attribute - not 
changing the existing markup like <div id=main>...</div> to another 
element (potentially requiring many changes to CSS and scripts) or 
redundantly using both the old markup and the new element around it.

This is different from standardizing class attribute values. Such 
standardization is questionable, since the class attribute is supposed 
to be authors' playground, mainly for styling, and assigning a meaning 
to any reasonable-looking class name would conflict with existing usage. 
So it's better to keep class free for authors' varying purposes and use 
a different attribute, with no prior use, to introduce new semantics.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/