[whatwg] New attributes would degrade better than new elements

[Ashley Sheridan]

On Thu, 2011-10-27 at 09:28 +0300, Jukka K. Korpela wrote:

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

Well, the <div> tag hasn't been around since the beginning, so someone
obviously thought it was useful enough to warrant being added. At the
time it was added there were two main browsers IE and Netscape
Navigator. IE supported <div> and Netscape supported <layer>, and both
had a fairly good market share. Were the specs stupid for picking one
they thought was useful and going with it?

> 
> > 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 were issues when HTML4 came along and added a bunch of new tags,
IE was still not handling <acronym> and <abbr> the same until a while
ago, which is probably why <acronym> was dropped.

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

<nav> is a block level element, so behaves as such in conforming
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.

Like I said before, if someone is using an older version of IE, it's
also likely that they will not have Javascript turned off. Nobody uses
an older version of IE by choice, if they knew another browser existed
they would use it. If they're in an environment where they can't change
it but want to, the last thing they'll do is block what little chance
they have of seeing the modern web.

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

What about <strong> and <b>? The former tag is what we have been told to
use going forward because of the context it adds, and this is true.
Google admits certain aspects of its indexing algorithm, and this is but
a little part of it. They would be certainly missing a trick if they
weren't also indexing based on HTML5 tags as well, adding context to a
page. Think about it, they can now identify key areas of your page if
you've marked it up correctly, which you can't do with HTML4.

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

What is the fear of adding new tags? You don't create a new XML document
with every tag as <tag> do you? For that same reason it makes sense to
use different tags for HTML elements. They are backwards compatible in
that browsers that don't understand them can just ignore them. You can
use other elements within them in a transitional phase of your
development if you really think you need to.

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



-- 
Thanks,
Ash
http://www.ashleysheridan.co.uk