Re: [whatwg] New attributes would degrade better than new elements
On Wed, 26 Oct 2011, Jukka K. Korpela wrote: New elements like nav and footer have the problem that some existing user agents don't recognize them, even for the purposes of styling. This is only a transient problem for a few years, and a minor one at that -- you can always add CSS to make them work in CSS-capable browsers, and it doesn't matter so much if they do nohting in non-CSS browsers. 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. Old IEs need a special trick. Other browsers really don't, unless you consider setting the element's 'display' property a trick. Therefore, it would be much simpler, for compatibility with existing user agents, to use just div type=nav and div type=footer. I think the ugliness of that solution far outweighs any temporary transition issue. 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. Actually this topic was discussed in depth. Nobody needs new elements with no required functionality, really. The idea of more compact markup is pointless. This view is not shared by all. Personally, for example, I find the terseness of different element names to be of much help in writing more maintainable documents. On Thu, 27 Oct 2011, Kang-Hao (Kenny) Lu wrote: What else use cases do they serve? (This is a serious question since I truly don't know.) Specific elements have specific purposes, e.g. nav allows ATs to jump to or past site navigation blocks, and section allows table of contents outlines to be created (as do h1-h6, but section allows you to do it without having to renumber all your headings when moving stuff around). But in general, the main purpose is easier authoring. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] New attributes would degrade better than new elements
2012-01-27 21:33, Ian Hickson wrote: On Wed, 26 Oct 2011, Jukka K. Korpela wrote: New elements likenav andfooter have the problem that some existing user agents don't recognize them, even for the purposes of styling. This is only a transient problem for a few years, and a minor one at that -- you can always add CSS to make them work in CSS-capable browsers, No, that won't work on still existing versions of IE. Old IEs need a special trick. Indeed. They require JavaScript code. Therefore, it would be much simpler, for compatibility with existing user agents, to use just div type=nav and div type=footer. I think the ugliness of that solution far outweighs any temporary transition issue. div type=nav has been used for years, and it did not become any uglier. Transient problems that will be with us for years, as you admitted, far outweigh any subjective esthetics of more compact markup. Personally, for example, I find the terseness of different element names to be of much help in writing more maintainable documents. Then you could use authoring tools that convert nav, or whatever you prefer, to markup that all browsers understand. But in general, the main purpose is easier authoring. It is not easier but more complicated, since you need to write CSS code _and_ JavaScript code just to make all browsers understand your nav the same way they would understand div class=nav. Yucca
Re: [whatwg] New attributes would degrade better than new elements
On Fri, 27 Jan 2012, Jukka K. Korpela wrote: 2012-01-27 21:33, Ian Hickson wrote: On Wed, 26 Oct 2011, Jukka K. Korpela wrote: New elements likenav andfooter have the problem that some existing user agents don't recognize them, even for the purposes of styling. This is only a transient problem for a few years, and a minor one at that -- you can always add CSS to make them work in CSS-capable browsers, No, that won't work on still existing versions of IE. Old IEs need a special trick. Indeed. They require JavaScript code. A trivial matter. Therefore, it would be much simpler, for compatibility with existing user agents, to use just div type=nav and div type=footer. I think the ugliness of that solution far outweighs any temporary transition issue. div type=nav has been used for years, and it did not become any uglier. I assume you mean div class=nav. Transient problems that will be with us for years, as you admitted, far outweigh any subjective esthetics of more compact markup. On the contrary. The transition issue is a short-term issue (on the scale of the age of the eventual period of time during which the features will exist), but the language design aesthetic is one that we will have to live with for the lifetime of the feature. Personally, for example, I find the terseness of different element names to be of much help in writing more maintainable documents. Then you could use authoring tools that convert nav, or whatever you prefer, to markup that all browsers understand. nav, to a sufficient approximation, is markup that all browsers understand. But in general, the main purpose is easier authoring. It is not easier but more complicated, since you need to write CSS code _and_ JavaScript code just to make all browsers understand your nav the same way they would understand div class=nav. This is a mere transition issue. You are welcome to avoid using the element for a few years until it becomes more widely supported. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] New attributes would degrade better than new elements
On Sun, Oct 30, 2011 at 11:50 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: There are no such plans. I'm not sure where you heard this, but it's definitely incorrect. ~TJ I didn't say that WHATWG is planning it but that I heard I believe from a talk on mozilla hacks by Chris Heilmann(but i could be wrong) about work on something to do layouts inside a webpage instead of using tables for layout. So it is probably some work by Mozilla. Summary: We should not discuss this issue as if it's only a matter of styling. You are right but I had no data to support this side of the argument.
Re: [whatwg] New attributes would degrade better than new elements
30.10.2011 1:18, Eric Sh. wrote: I heard there are plans to create new tags for layouts to replace the use of tables as layout elements. Maybe such rumors have been caused by taking some parody for real. You keep speaking of creating new attributes instead of adding new tags but then what is the point in adding new attributes instead of simply using classes which are far more compatible on past browsers? That would correspond to the microformats approach, which is the simplest way of adding low-level metadata. But it seems that the search engine consortium decided to favor another approach, microdata. Note that it does not use new elements - even though it adds completely new semantics - but new attributes. I think I have mentioned the class attribute in this discussion, as well as the point that using class to add semantics could conflict with existing usage. When authors have written div class=nav, they didn't expect browsers or other software to start treating the element in their own ways, according to some future specification. They expected the class name space to be for them to use freely. One might ask how often does a class name like nav relate to something else than a navigation block, in practice. In theory, it could be just anything, of course. And while div class=nav.../div is a common paradigm, div class=article.../div is not, and article might well have been used as a class name with no intent of declaring the content as a syndicatable article or getting some special default article styling that browsers might apply. And WHATWG is working hard to ensure compatability of new additions with old browsers(the DOCTYPE for example). I don't see how the DOCTYPE trickery relates to this. The only things that the !doctype html construct achieves are putting browsers to standards more (something that can be achieved by the use of any private doctype declaration) and informing validators (linters) that they should treat the document according to what happens to be the Living Standard's content today. So I am positive issues like this one were already discussed and dismissed for some reason or another, I am positive that if there were a solid ground for the introduction of new elements like nav, article, etc., it would already have been presented in this discussion, if not in the Living Standard itself. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] New attributes would degrade better than new elements
2011-10-30 00:18, Eric Sh. skrev: I heard there are plans to create new tags for layouts to replace the use of tables as layout elements. You have heard exactly what? Where? Spoke by whom? That would certainly be very controversial! -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Re: [whatwg] New attributes would degrade better than new elements
On Sat, Oct 29, 2011 at 3:18 PM, Eric Sh. shedok...@gmail.com wrote: On Sat, Oct 29, 2011 at 3:38 PM, Jukka K. Korpela jkorp...@cs.tut.fiwrote: It is certainly wise to keep table as dual (tabular data vs. layout) for compatibility, instead of introducing new elements to distinguish them - no matter how logical or semantic such an idea might sound. I heard there are plans to create new tags for layouts to replace the use of tables as layout elements. There are no such plans. I'm not sure where you heard this, but it's definitely incorrect. ~TJ
Re: [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/
Re: [whatwg] New attributes would degrade better than new elements
27.10.2011 3:11, Ashley Sheridan wrote: Try telling me Google isn't aware of HTML5 in web pages and I'll laugh. OK, I'll try: Google does not care about new HTML5 elements. Do you feel amused now? Can you please now do me, and others, a favor and give some evidence of actual Google behavior in this respect? If it's something that we need to be aware of, it should be observable from outside Google, i.e. when using Google, not just in their internal code that is not public. So which effects can we observe? (This would be interesting in its own account, even though it does not prove that new _elements_ were needed for that. But it would give some perspective regarding the eagerness to add and promote new elements.) - - you shouldn't use attributes to determine the meaning of the content. That sounds like a prejudice based on the introduction of many presentational attributes in HTML 3.2 and their preservation in later versions. It does not in any way mean that attributes as such are presentational and not semantic. HTML5 tries hard to distinguish between table indicating tabular data and table being used merely as layout tool - and the distinction is largely based on the use of attributes in the table element and its descendants. It is certainly wise to keep table as dual (tabular data vs. layout) for compatibility, instead of introducing new elements to distinguish them - no matter how logical or semantic such an idea might sound. Using attributes in div to indicate navigational areas, articles, etc., would similarly be useful for compatibility and would be much clearer and more logical, as the meaning would be uniquely defined by a single attribute - not by some rather messy rules involving several elements and attributes. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] New attributes would degrade better than new elements
On Sat, 2011-10-29 at 16:38 +0300, Jukka K. Korpela wrote: Can you please now do me, and others, a favor and give some evidence of actual Google behavior in this respect? If it's something that we need to be aware of, it should be observable from outside Google, i.e. when using Google, not just in their internal code that is not public. So which effects can we observe? I stand corrected, Google doesn't yet do this. - - you shouldn't use attributes to determine the meaning of the content. That sounds like a prejudice based on the introduction of many presentational attributes in HTML 3.2 and their preservation in later versions. It does not in any way mean that attributes as such are presentational and not semantic. It's not prejudice, it's observation. With the exception of the a tag that I mentioned and the input tag that Boris Zbarsky mentioned, HTML tags are used to describe the content they contain and not attributes of a generic tag. instead of introducing new elements to distinguish them - no matter how logical or semantic such an idea might sound. Using attributes in div to indicate navigational areas, articles, etc., would similarly be useful for compatibility and would be much clearer and more logical, as the meaning would be uniquely defined by a single attribute - not by some rather messy rules involving several elements and attributes. In the same way that semantic tags were added in HTML4 instead of backwards compatible attributes the HTML5 specs are adding new tags. You keep mentioning that we should use div tags for everything that the new HTML5 tags are being used for now, but you seem to forget that this is just the same situation as we had years ago when HTML4 was announced as a spec. Why was it OK to introduce new tags then but not now? -- Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] New attributes would degrade better than new elements
On Sat, Oct 29, 2011 at 3:38 PM, Jukka K. Korpela jkorp...@cs.tut.fiwrote: It is certainly wise to keep table as dual (tabular data vs. layout) for compatibility, instead of introducing new elements to distinguish them - no matter how logical or semantic such an idea might sound. I heard there are plans to create new tags for layouts to replace the use of tables as layout elements. You keep speaking of creating new attributes instead of adding new tags but then what is the point in adding new attributes instead of simply using classes which are far more compatible on past browsers? And WHATWG is working hard to ensure compatability of new additions with old browsers(the DOCTYPE for example). So I am positive issues like this one were already discussed and dismissed for some reason or another, have you tried searching the archives? maybe there you'll find the answers you are looking for. Regards, Eric
Re: [whatwg] New attributes would degrade better than new elements
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/
Re: [whatwg] New attributes would degrade better than new elements
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
Re: [whatwg] New attributes would degrade better than new elements
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. 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. 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. 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 navdiv class=nav.../div/nav and they would have to do all the styling and scripting on the div element. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] New attributes would degrade better than new elements
On Wed, 26 Oct 2011 23:36:23 +0200, Jukka K. Korpela jkorp...@cs.tut.fi wrote: So, it's not a big deal. It's difference between working on all browsers and working on some browsers as well as being tweakable when JavaScript is enabled. div type=nav is not stylable in IE6 because it doesn't support attribute selectors. -- Simon Pieters Opera Software
Re: [whatwg] New attributes would degrade better than new elements
27.10.2011 11:42, Simon Pieters wrote: It's difference between working on all browsers and working on some browsers as well as being tweakable when JavaScript is enabled. div type=nav is not stylable in IE6 because it doesn't support attribute selectors. Granted, but a) IE6 is dying, whereas IE7 and IE8 are and will be with us for a long time, and they do support attribute selectors b) if you regard IE6 as still relevant, you can additionally use a class or id attribute (or keep it, if working with an existing document); on IE6, they work for div but not for nav as the entire element is unknown. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] New attributes would degrade better than new elements
How does this relate to the question of adding element vs. adding attributes? I am saying that they also added div which is the most famous tag to date(added in HTML 4), so maybe we should have used tag type=div and tag type=img that way all browsers would support it no? They could do just the same with div type=article. Don't you think that it rather lengthy way of saying the same thing? _I_ am not stupid, and I did not come to think of this earlier. Did I say you were? All I said is that you are underestimating the knowledge of the specification makers throughout the years. What is the fear of adding new tags? Compatibility with older browsers. It should not be broken without due cause. 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. It looks like you missed the part of http://ejohn.org/blog/html5-shiv/ where it shows you that styling DOES work on browses without HTML 5 support. And the number of browsers who do not support HTML 5 tags and have javascript disabled is far too little in my opinion for any website to try and support. b) if you regard IE6 as still relevant, you can additionally use a class or id attribute (or keep it, if working with an existing document); on IE6, they work for div but not for nav as the entire element is unknown. If you create the element using javascript then the tag name IS known and styleable. From what it looks like your solution only makes html documents bigger and harder to write(not to mention the pains of css and attributes across browsers), and also against the entire HTML history where the tag name is used(almost always) to define it's contents and not one of it's attributes. And the more time you keep having support for too old browsers the harder it is for web developers to keep up with all browsers and advance the web and make it better. Do you think we should have elements like menu and canvas as div type=menu and div type=canvas? And last thing - what can we do with browsers that already support this? This is a major technical problem and you haven't said anything on this front.
Re: [whatwg] New attributes would degrade better than new elements
Jukka K. Korpela jkorp...@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 acronymwas, 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 navdiv 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.
[whatwg] New attributes would degrade better than new elements
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. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] New attributes would degrade better than new elements
Jukka K. Korpela jkorp...@cs.tut.fi schrieb am Wed, 26 Oct 2011 22:38:06 +0300: 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? I'd argue it is: http://caniuse.com/html5semantic -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] New attributes would degrade better than new elements
(11/10/27 3:38), Jukka K. Korpela wrote: Nobody needs new elements with no required functionality, really. The idea of more compact markup is pointless. Every time I ask myself what the use cases of the semantic elements are, my only answer is it makes existing markup shorter. What else use cases do they serve? (This is a serious question since I truly don't know.) (11/10/27 3:38), Jukka K. Korpela wrote: People don't read or write markup that much, I doubt it.
Re: [whatwg] New attributes would degrade better than new elements
On Wed, Oct 26, 2011 at 12:38 PM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 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. Believe me, these discussions were had in the past. All major UAs except old IE handle unknown elements in a way that's acceptable for nav and friends. They have the absolute default styling (such as display:inline), but that's fine, as you can still target them and restyle them. In old IE the new elements are instead parsed as two void elements named nav and /nav, but the IE shiv has been around for years now that fixes that with a one-liner in JS. Once you run that, you're in the same situation as other major browsers. So, it's not a big deal. (Plus, modern browsers *do* recognize the new elements natively now.) ~TJ
Re: [whatwg] New attributes would degrade better than new elements
On Thu, 2011-10-27 at 04:14 +0800, Kang-Hao (Kenny) Lu wrote: (11/10/27 3:38), Jukka K. Korpela wrote: Nobody needs new elements with no required functionality, really. The idea of more compact markup is pointless. Every time I ask myself what the use cases of the semantic elements are, my only answer is it makes existing markup shorter. Think about what semantic means. In this context, it's about the meaning of the tag to give a context to its contents. A user agent (not the same thing as a browser) doesn't know what div id=nav is, but the modern ones do know what nav is, and what it means. You might not be able to see the use case, but trust me, plenty of other people do, including those behind things like search engines. What else use cases do they serve? (This is a serious question since I truly don't know.) (11/10/27 3:38), Jukka K. Korpela wrote: People don't read or write markup that much, I doubt it. The reason for the new semantic tags is because of an effort to look at what were common elements of pre-HTML5 pages and try to identify parts of a web page that were most common. This led to things like header, footer, nav, section and article being created and adopted by the modern browsers and user agents. If we didn't have them, we'd be back to using divs everywhere, with a mixed assortment of classes and id's used to style them, and to hell with any search engines that tried to understand our web pages. For the same reason that it's better to mark up our text with strong than b it's also better to mark up our pages using the new tags as they give a meaning to areas of our pages that we want. If you don't care about search engines or blind visitors, then don't bother using them. -- Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] New attributes would degrade better than new elements
26.10.2011 23:16, Tab Atkins Jr. wrote: Believe me, these discussions were had in the past. I do, but did you draw the conclusions? All major UAs except old IE handle unknown elements in a way that's acceptable That means all browsers except that the most common one. Is that a realistic view? What do you expect to gain by adding new elements, as opposite to the smoother addition of new attributes? So, it's not a big deal. It's difference between working on all browsers and working on some browsers as well as being tweakable when JavaScript is enabled. Under which circumstances would you vote for the latter, and what do you expect to win? I love gambling, but what's the potential gain here? Pleasing someone's idea of semantic markup, as if attributes could not be semantic? -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] New attributes would degrade better than new elements
On Thu, 2011-10-27 at 00:36 +0300, Jukka K. Korpela wrote:
26.10.2011 23:16, Tab Atkins Jr. wrote:
Believe me, these discussions were had in the past.
I do, but did you draw the conclusions?
All major UAs except old IE handle unknown elements in a way that's
acceptable
That means all browsers except that the most common one. Is that a
realistic view?
Yes it is I think. If people are using versions of IE that old, then
they deserve to have an older version of the web given to them. There
are plenty of browsers available for even the older operating systems
(Chrome, Opera, Firefox) so not having a new one available is no excuse.
What do you expect to gain by adding new elements, as opposite to the
smoother addition of new attributes?
Why is adding attributes smoother? User agents still have to be modified
to 'understand' an attribute to make the same semantic sense as a new
tag, so you gain nothing. You're just swapping one flavour for another.
So, it's not a big deal.
It's difference between working on all browsers and working on some
browsers as well as being tweakable when JavaScript is enabled.
If you're using an older version of IE then likely it's because you
don't know any different, and also likely that you don't even know what
Javascript is, let alone know how to disable it. I can't back this up
with facts, just personal experience.
Under which circumstances would you vote for the latter, and what do you
expect to win? I love gambling, but what's the potential gain here?
Pleasing someone's idea of semantic markup, as if attributes could not
be semantic?
Attributes can be semantic, but where do you draw the line? From what
you're saying, all tags in HTML could be reconciled into one and you can
just use attributes to differentiate:
tag type=image src=blah.png
tag type=paratext/tag
tag type=italictext/tag
tag type=css.blue{color:#00f;}/tag
Would you really favour using attributes to determing the meaning of a
tag, or would you rather that HTML just follows its natural course and
attributes be used to supplement a tag from default values?
--
Thanks,
Ash
http://www.ashleysheridan.co.uk
Re: [whatwg] New attributes would degrade better than new elements
27.10.2011 0:57, Ashley Sheridan wrote: If people are using versions of IE that old, then they deserve to have an older version of the web given to them. That's rather elitistic, given the fact that many people have no way of upgrading their IE or switching to your preferred browser, and no need to do that apart from some ideas of HMTL5. Why is adding attributes smoother? Browsers recognize the elements. User agents still have to be modified to 'understand' an attribute to make the same semantic sense as a new tag What semantic sense? Exactly what do modern browsers understand about nav for example? What are they required to understand? Just that there's a styleable element. But with div, that's something we have with all browsers. The difference is between fancy new elements and good old elements with new attributes. If you're using an older version of IE then likely it's because you don't know any different That's rather elitistic, isn't it? If we could discard all bad browsers, the world would be nicer, yes, but then we would not really have any browsers, would we? Attributes can be semantic, but where do you draw the line? In the definition of the attributes. If you can make up a new element like nav, why can't you make up a new attribute like type=nav? Would you really favour using attributes to determing the meaning of a tag, or would you rather that HTML just follows its natural course and attributes be used to supplement a tag from default values? Neither attributes nor tag names mean anything by themselves. They get their meanings from specifications or from browser practices. The question is whether the new semantic tags have any useful impact (what might it be?). Inventing new tags may sound cooler than defining meanings for attributes, but it's just an idle game. Is there _any_ demonstrable use of, say, the semantics of nav? And what's the reason why that could not be achieved in the less disruptive way of assigning a standardized meaning to, say, the type attribute of div? -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] New attributes would degrade better than new elements
On Thu, 2011-10-27 at 02:37 +0300, Jukka K. Korpela wrote: 27.10.2011 0:57, Ashley Sheridan wrote: If people are using versions of IE that old, then they deserve to have an older version of the web given to them. That's rather elitistic, given the fact that many people have no way of upgrading their IE or switching to your preferred browser, and no need to do that apart from some ideas of HMTL5. Yes, but then I have to deal with the pain of old versions of IE every day, so my view is not without cause. Why is adding attributes smoother? Browsers recognize the elements. Browsers also recognise HTML5 elements. Going back to a link that someone posted earlier http://caniuse.com/html5semantic it's clear to see that of the 64 browsers listed (including each unique version number as distinct and grouping both occurances of IE9.0 as 1) then it's clear to see that the browsers *not* supporting HTML5 (of which there are 5) are in the minority with regards to all the browsers out there (at least those tested, which does not include some of the more minor browsers such as Konqueror, Galeon Epiphany on desktops and things like Firefox, Dolphin and Boat for Android, for example) User agents still have to be modified to 'understand' an attribute to make the same semantic sense as a new tag What semantic sense? Exactly what do modern browsers understand about nav for example? What are they required to understand? Just that there's a styleable element. But with div, that's something we have with all browsers. It's not just about browsers don't forget, there are other things out there too that visit websites, such as search engines. Try telling me Google isn't aware of HTML5 in web pages and I'll laugh. The semantic value is there also for things like speech and Braille browsers too, which can use HTML5 to aid navigation, by offering differences in the way that nav elements are presented, and easy navigation between sections and articles. The difference is between fancy new elements and good old elements with new attributes. If you're using an older version of IE then likely it's because you don't know any different That's rather elitistic, isn't it? Not really, it's what I've observed to be true. I'm not saying that if you're using an old version of IE that you *must* not know about any different browsers, but that it's more likely that you don't. If we could discard all bad browsers, the world would be nicer, yes, but then we would not really have any browsers, would we? Attributes can be semantic, but where do you draw the line? In the definition of the attributes. If you can make up a new element like nav, why can't you make up a new attribute like type=nav? Because that's how HTML works. You don't just add new attributes to things that exist already to create a whole new meaning for something. You advocate using div tags with custom attributes, but they weren't part of the standard until HTML4. Should we have stopped back then and say we don't need new tags, let's just add attributes to the ones we have already? No, new tags were added to the spec because it was felt they were needed. Would you really favour using attributes to determing the meaning of a tag, or would you rather that HTML just follows its natural course and attributes be used to supplement a tag from default values? Neither attributes nor tag names mean anything by themselves. They get their meanings from specifications or from browser practices. The question is whether the new semantic tags have any useful impact (what might it be?). Inventing new tags may sound cooler than defining meanings for attributes, but it's just an idle game. Is there _any_ demonstrable use of, say, the semantics of nav? And what's the reason why that could not be achieved in the less disruptive way of assigning a standardized meaning to, say, the type attribute of div? Because you shouldn't use attributes to determine the meaning of the content. There's only one such example I can think of where an attribute totally changes the meaning of a tag, and there were calls for getting rid of that ambiguity in HTML5. I speak of the a tag of course, and its double nature as both a link and an anchor. All the other HTML tags are specific and described in their behaviour and meaning for the content they contain, and use attributes only to enhance, supplement or subtly alter their basic function. A p tag is always used for paragraphs, an img tag is always used for images, script is always used for script, etc. nav seems like a perfectly logical choice of tag to add to the spec, as it's a rare day you ever see a website without a navigation bar of some sort; it makes sense. -- Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] New attributes would degrade better than new elements
If the web was only using the first tags such as(I think) pre then the web woul not be where it is today. 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. 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. I believe that the decision makers are not stupid, they are smart enough to know all these technical issues and conflicts with conflicts that may arrise with additions like this one, and I also believe that they have far more knowledge of this subject and everything that will be changed by a new feature(browsers, search engines, speech browsers, and other UA's) 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!)
