[whatwg] New attributes would degrade better than new elements
Ashley Sheridan
ash at ashleysheridan.co.uk
Thu Oct 27 02:36:58 PDT 2011
"Jukka K. Korpela" <jkorpela at cs.tut.fi> wrote:
>27.10.2011 9:55, Ashley Sheridan wrote:
>
>>> 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 if <div type=nav> were used, it would be rendered as a block in
>nonconforming browsers too. (The point about more or less required
>default rendering with display: block is taken as a correction to my
>statement above, but it does not really change my point. Rather,
>strengthens it.)
>
>> What about <strong> and <b>?
>
>Yes, what about them? They have been in HTML since the very beginning.
Erm, what?! <b> might have been there from the beginning, but <strong> was only added in HTML4, the same time <acronym>was, and IE didn't support that at the time.
>If you were to add _new_ markup for emphasis into HTML, I would suggest
>
>that you don't add a new element, like <key>, but rather an attribute -
>
>to an element that comes closest in meaning and default rendering, like
>
><strong type=key> or <b type=key>.
>
>> 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.
>
>There's a lot we can speculate about potential use of the new markup
>elements and remarkably little factual evidence. But surely if Google
>can recognize <nav> and make some use of it, it could deal with <div
>type=nav> as well.
>
>> What is the fear of adding new tags?
>
>Compatibility with older browsers. It should not be broken without due
>cause.
There is good cause. If we pandered to old browsers (IE) then we would be years behind where we are now. It was only because of efforts like Firefox that IE started to make an effort with their browser again. It sounds elitist, and I am to a point, but there has to be a time when developers just say enough is enough and move forward with the web in a way that is beneficial to the majority of people. Just look at the stats at w3schools.
>
>> You don't create a new XML document
>> with every tag as <tag> do you?
>
>HTML isn't XML. Or, to the extent that it is XML (serialized as XML),
>it
>has a specific HTML vocabulary recognized by browsers and other
>HTML-aware software.
>
>> They are backwards compatible in
>> that browsers that don't understand them can just ignore them.
>
>That's exactly the point that causes the incompatibility: to a browser
>that does not recognize <nav> at all, your CSS settings for it are
>ignored and it isn't even rendered as a block by default.
Prompting the user to ask themselves why things look strange and make an effort to upgrade their browser.
>
>> You can
>> use other elements within them in a transitional phase of your
>> development if you really think you need to.
>
>So in any reasonable use now or some years from now, the new markup
>that
>was supposed to simplify markup will make markup more lengthy and less
>logical. Instead of
><div class=nav>...</div>
>authors would need to use
><nav><div class=nav>...</div></nav>
Not really, you don't have to give every element you style a class of its own.
>and they would have to do all the styling and scripting on the div
>element.
As mentioned before, html shiv allows Javascript to makeold IE aware of the new elements. You can say they turn off script, but you won't give an example of someone using an old IE that would do that.
>
>--
>Yucca, http://www.cs.tut.fi/~jkorpela/
Thanks,
Ash
http://www.ashleysheridan.co.uk
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
More information about the whatwg
mailing list