Comments on: HTML 5: nav ambiguity resolved http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/ Web design news and insights since 1995 Sat, 20 Mar 2010 00:13:58 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Jean Ximenes - <Jean´s Blog /> http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-51527 Jean Ximenes - <Jean´s Blog /> Wed, 06 Jan 2010 12:12:30 +0000 http://www.zeldman.com/?p=1674#comment-51527 <!--%kramer-ref-pre%-->[...] demosBespin, by mozillaDoctor, te ajudando a implemetar html5 agoraCanvas e sua acessibilidadeTag nav, por zeldman.comLista de características suportadas, by Molly.comBlog Whatwg.orgCanvas, by dev.operaUfaaa... tem [...]<!--%kramer-ref-post%--> [...] demosBespin, by mozillaDoctor, te ajudando a implemetar html5 agoraCanvas e sua acessibilidadeTag nav, por zeldman.comLista de características suportadas, by Molly.comBlog Whatwg.orgCanvas, by dev.operaUfaaa… tem [...]

]]> By: html5 web resources start learn there « Just Press it! http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-51184 html5 web resources start learn there « Just Press it! Thu, 24 Dec 2009 04:30:07 +0000 http://www.zeldman.com/?p=1674#comment-51184 [...] HTML 5: nav ambiguity resolved – A post by Zeldman on the HTML 5 Nav element [...] [...] HTML 5: nav ambiguity resolved – A post by Zeldman on the HTML 5 Nav element [...]

]]> By: engettals http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-50974 engettals Sun, 13 Dec 2009 17:57:49 +0000 http://www.zeldman.com/?p=1674#comment-50974 Sry for commenting off topic ... which Word Press theme are you using? It's looking awesome! Sry for commenting off topic … which Word Press theme are you using? It’s looking awesome!

]]> By: pwb http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-49504 pwb Sun, 01 Nov 2009 19:14:49 +0000 http://www.zeldman.com/?p=1674#comment-49504 Amen, John and Luke (the apostles?). The direction HTML5 is going with header, article, nave, etc. elements is horrible. HTML5 should address major pain points or major innovations. Not little tweaks that increase confusion and provide little or no value (or even negative value). Amen, John and Luke (the apostles?). The direction HTML5 is going with header, article, nave, etc. elements is horrible. HTML5 should address major pain points or major innovations. Not little tweaks that increase confusion and provide little or no value (or even negative value).

]]> By: Brady J. Frey http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-49497 Brady J. Frey Sun, 01 Nov 2009 06:12:31 +0000 http://www.zeldman.com/?p=1674#comment-49497 I just read this article now, and I always find it funny that 'div class="navigation"' instead of 'div id="navigation"' is the standard... I've yet to find a situation where I've needed to call a set of navigation values, with the exact same style/effects, twice. I just read this article now, and I always find it funny that ‘div class=”navigation”‘ instead of ‘div id=”navigation”‘ is the standard… I’ve yet to find a situation where I’ve needed to call a set of navigation values, with the exact same style/effects, twice.

]]> By: Fundamentally Navigable « IntelDesigner http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-48943 Fundamentally Navigable « IntelDesigner Thu, 15 Oct 2009 17:30:00 +0000 http://www.zeldman.com/?p=1674#comment-48943 [...] Soon after this post was made Jeffery Zeldman made a post on HTML 5 that will enable a higher level of semantic code for [...] [...] Soon after this post was made Jeffery Zeldman made a post on HTML 5 that will enable a higher level of semantic code for [...]

]]> By: Webkrauts » Das Endoskelett einer Webseite http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-48859 Webkrauts » Das Endoskelett einer Webseite Fri, 02 Oct 2009 07:41:02 +0000 http://www.zeldman.com/?p=1674#comment-48859 <!--%kramer-ref-pre%-->[...] XHTML 2.0 ist tot, wie man weiß, aber in meinen Augen steht auch HTML5 alles andere als mitten im Leben. Ja, man kann vieles heute schon einsetzen und ja, der Doctype schadet (noch) niemandem. Die wirklich wichtigen Neuerungen, z.B. lokale Datenbanken, sind aber wahrscheinlich erst dann wirklich implementiert, wenn man schon wieder etwas anderes bräuchte. We don’t need to predict the future. When the future comes, we can just fix HTML again. It’s more important that HTML caters to the present than to the future. Ian Hickson [...]<!--%kramer-ref-post%--> [...] XHTML 2.0 ist tot, wie man weiß, aber in meinen Augen steht auch HTML5 alles andere als mitten im Leben. Ja, man kann vieles heute schon einsetzen und ja, der Doctype schadet (noch) niemandem. Die wirklich wichtigen Neuerungen, z.B. lokale Datenbanken, sind aber wahrscheinlich erst dann wirklich implementiert, wenn man schon wieder etwas anderes bräuchte. We don’t need to predict the future. When the future comes, we can just fix HTML again. It’s more important that HTML caters to the present than to the future. Ian Hickson [...]

]]> By: SimpleBits ~ July 2009 Archives http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-48831 SimpleBits ~ July 2009 Archives Mon, 28 Sep 2009 17:01:09 +0000 http://www.zeldman.com/?p=1674#comment-48831 <!--%kramer-ref-pre%-->[...] —John Allsopp [...]<!--%kramer-ref-post%--> [...] —John Allsopp [...]

]]> By: HTML5ѧϰԴ-HTML/Xhtml-ҳ-ҳѧ http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-48542 HTML5ѧϰԴ-HTML/Xhtml-ҳ-ҳѧ Tue, 22 Sep 2009 03:34:11 +0000 http://www.zeldman.com/?p=1674#comment-48542 <!--%kramer-ref-pre%-->[...] element Thinking About HTML 5 canvas Accessibility A post by Zeldman on the HTML 5 Nav element HTML 5: nav ambiguity resolved A great list from Molly about which HTML 5 features are supported by which browsers A Selection of [...]<!--%kramer-ref-post%--> [...] element Thinking About HTML 5 canvas Accessibility A post by Zeldman on the HTML 5 Nav element HTML 5: nav ambiguity resolved A great list from Molly about which HTML 5 features are supported by which browsers A Selection of [...]

]]> By: Bert http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-48179 Bert Mon, 07 Sep 2009 22:41:47 +0000 http://www.zeldman.com/?p=1674#comment-48179 I have studies the HTML5 spec for the past year on and off. I voiced some of my concerns to the list... to no avail. I see the spec as 2 different specs rolled into 1. On the one had we have the markup, and on the other we have something which I can only describe as a manual for building browsers (which includes some new technologies which can only be named WebApps). As far as the manual part is concerned, I can only say that most of that new stuff is already feasible by using things like JavaScript, PHP, Ruby, Flash etc. For the rest, as a designer I couldn't care less about how browsers should be built...as long as they work. But, when it come to the markup side of the spec; seriously, wouldn't it have been better to aim our focus on assistive technologies and progression of separation of content and style? In the end, honestly, who or what cares if I use _div class=header_ or _header_ ?? Most of us are debating when IE will implement this, but wouldn't the real question be when will speech engines implement it? and when they do, will it improve accessibility? So now I can wrap my menu in a NAV element (which is just a dupe of the UL). Wow, great..I can finally sleep at night. What will this accomplish? Even worse, I could always have done that. FF, Opera and Safari will let you use any made-up name for an element, they will render it, they will style it. And with a little javascript, so will IE. Hell, I can create a website with just 9 (HTML401) elements which is valid, accessible and what more. None would be the wiser for it unless they would view my source code manually. The only conclusion I can come to is that the HTML5 spec abuses HTML to create a platform to enable Google, Mozilla, etc. to being more competitive against MS. I'm sorry, but this is the browser wars all over again, and this time they have nuke's!!! I have studies the HTML5 spec for the past year on and off. I voiced some of my concerns to the list… to no avail.
I see the spec as 2 different specs rolled into 1. On the one had we have the markup, and on the other we have something which I can only describe as a manual for building browsers (which includes some new technologies which can only be named WebApps).

As far as the manual part is concerned, I can only say that most of that new stuff is already feasible by using things like JavaScript, PHP, Ruby, Flash etc. For the rest, as a designer I couldn’t care less about how browsers should be built…as long as they work.

But, when it come to the markup side of the spec; seriously, wouldn’t it have been better to aim our focus on assistive technologies and progression of separation of content and style? In the end, honestly, who or what cares if I use _div class=header_ or _header_ ?? Most of us are debating when IE will implement this, but wouldn’t the real question be when will speech engines implement it? and when they do, will it improve accessibility?
So now I can wrap my menu in a NAV element (which is just a dupe of the UL). Wow, great..I can finally sleep at night. What will this accomplish? Even worse, I could always have done that. FF, Opera and Safari will let you use any made-up name for an element, they will render it, they will style it. And with a little javascript, so will IE.
Hell, I can create a website with just 9 (HTML401) elements which is valid, accessible and what more. None would be the wiser for it unless they would view my source code manually.

The only conclusion I can come to is that the HTML5 spec abuses HTML to create a platform to enable Google, Mozilla, etc. to being more competitive against MS. I’m sorry, but this is the browser wars all over again, and this time they have nuke’s!!!

]]> By: Death To The Div » CSS/HTML, Coding, Rant » Russell Heimlich http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-48044 Death To The Div » CSS/HTML, Coding, Rant » Russell Heimlich Wed, 02 Sep 2009 03:57:33 +0000 http://www.zeldman.com/?p=1674#comment-48044 <!--%kramer-ref-pre%-->[...] make sure every browser can support whatever element we can come up with. After all we only have one shot to get HTML right for this generation according to John [...]<!--%kramer-ref-post%--> [...] make sure every browser can support whatever element we can come up with. After all we only have one shot to get HTML right for this generation according to John [...]

]]> By: The HTML5 Semantics Debate - ComponentGear.com Feed - ComponentGear.com http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-47945 The HTML5 Semantics Debate - ComponentGear.com Feed - ComponentGear.com Mon, 31 Aug 2009 18:54:18 +0000 http://www.zeldman.com/?p=1674#comment-47945 <!--%kramer-ref-pre%-->[...] Jeffrey Zeldman approximates this “middle of the road” position, especially in the comments thread here. [...]<!--%kramer-ref-post%--> [...] Jeffrey Zeldman approximates this “middle of the road” position, especially in the comments thread here. [...]

]]> By: CSS3 y HTML5: Tutoriales y recursos para el nuevo diseño web | Recursos para desarrollo y diseño web - AlmacenPlantillasWeb Blog http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-47921 CSS3 y HTML5: Tutoriales y recursos para el nuevo diseño web | Recursos para desarrollo y diseño web - AlmacenPlantillasWeb Blog Mon, 31 Aug 2009 08:48:28 +0000 http://www.zeldman.com/?p=1674#comment-47921 [...] HTML 5: Nav Ambiguity Resolved – Información sobre el elemento “nav” en HTML 5. [...] [...] HTML 5: Nav Ambiguity Resolved – Información sobre el elemento “nav” en HTML 5. [...]

]]> By: Ben http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-47655 Ben Thu, 27 Aug 2009 07:52:36 +0000 http://www.zeldman.com/?p=1674#comment-47655 As another relative newbie (I've been doing this professionally for 2 years since I finished university), I have to agree with everyone who is saying that <b>nav, header, footer, aside</b>, etc, with no clear idea of where exactly we can and can't them, seem to be an overly complicated way of defining a <b>div</b> with a class="nav". @Ian Hickson <blockquote> How do you do drag-and-drop, canvas, video, native and accessible progress bars, calendar widgets, range controls, colour pickers, etc, in HTML4? </blockquote> Most people i've talked to are excited about these features! These aren't the ones that we have a gripe with. A video is a video, a calendar is a calendar, a progress bar is a progress bar. These make sense, and as you say, there is no way to implement them at the moment without the convoluted use of JavaScript and plugins. It's those others that seem to most of us to be nothing more than glorified <b>div</b>'s. It's going to take more than the occasional shout of "SEMANTICS! SCREENREADERS!" to gain acceptance for these elements. We need to know WHY they are necessary, and WHERE to use them. The currently offered answers to these two questions are far too vague and fluffy to be meaningful. As another relative newbie (I’ve been doing this professionally for 2 years since I finished university), I have to agree with everyone who is saying that nav, header, footer, aside, etc, with no clear idea of where exactly we can and can’t them, seem to be an overly complicated way of defining a div with a class=”nav”.

@Ian Hickson

How do you do drag-and-drop, canvas, video, native and accessible progress bars, calendar widgets, range controls, colour pickers, etc, in HTML4?

Most people i’ve talked to are excited about these features! These aren’t the ones that we have a gripe with.

A video is a video, a calendar is a calendar, a progress bar is a progress bar. These make sense, and as you say, there is no way to implement them at the moment without the convoluted use of JavaScript and plugins.

It’s those others that seem to most of us to be nothing more than glorified div’s. It’s going to take more than the occasional shout of “SEMANTICS! SCREENREADERS!” to gain acceptance for these elements.

We need to know WHY they are necessary, and WHERE to use them. The currently offered answers to these two questions are far too vague and fluffy to be meaningful.

]]> By: Juli 2009 im Kontext | hyperkontext | Weblog http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-47565 Juli 2009 im Kontext | hyperkontext | Weblog Mon, 24 Aug 2009 14:49:05 +0000 http://www.zeldman.com/?p=1674#comment-47565 <!--%kramer-ref-pre%-->[...] es wird auch heftig diskutiert: HTML 5: nav ambiguity resolved [Jeffrey [...]<!--%kramer-ref-post%--> [...] es wird auch heftig diskutiert: HTML 5: nav ambiguity resolved [Jeffrey [...]

]]>