13 Jul 2009 8 am eastern

HTML 5: nav ambiguity resolved

AN EMAIL from Chairman Hickson resolves an ambiguity in the nav element of HTML 5.

One of the new things HTML 5 sets out to do is to provide web developers with a standardized set of semantic page layout structures. For example, it gives us a nav element to replace structures like div class="navigation".

This is exciting, logical, and smart, but it is also controversial.

The controversy is best expressed in John Allsopp’s A List Apart article, Semantics in HTML 5, where he worries that the new elements may not be entirely forward-compatible, as they are constrained to today’s understanding of what makes up a page. An extensible mechanism, although less straightforward, would offer more room to grow as the web evolves, Allsopp argues.

We’re pretty sure Ian Hickson, the main force behind HTML 5, has heard that argument, but HTML 5 is proceeding along the simpler and more direct line of adding page layout elements. The WHAT Working Group Mr Hickson chairs has solicited designer and developer opinion on typical web page structures in order to come up with a short list of new elements in HTML 5.

nav is one of these elements, and its description in the spec originally read as follows:

The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links. Not all groups of links on a page need to be in a nav element — only sections that consist of primary navigation blocks are appropriate for the nav element.

The perceived ambiguity was expressed by Bruce Lawson (AKA HTML 5 Doctor) thusly:

“Primary navigation blocks” is ambiguous, imo. A page may have two nav blocks; the first is site-wide naviagtion (“primary navigation”) and within-page links, eg a table of contents which many would term “secondary nav”.

Because of the use of the phrase “primary navigation block” in the spec, a developer may think that her secondary nav should not use a

Chairman Hickson has resolved the ambiguity by changing “primary” to “major” and by adding an example of secondary navigation using nav.

Read more

  • Web Fonts, HTML 5 Roundup: Worthwhile reading on the hot new web font proposals, and on HTML 5/CSS 3 basics, plus a demo of advanced HTML 5 trickery. — 20 July 2009
  • Web Standards Secret Sauce: Even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. Thanks largely to the success of the iPhone, Webkit, in the form of Safari, has been a surprising force for good on the web, raising people’s expectations about what a web browser can and should do, and what a web page should look like. — 12 July 2009
  • In Defense of Web Developers: Pushing back against the “XHTML is bullshit, man!” crowd’s using the cessation of XHTML 2.0 activity to condescend to—or even childishly glory in the “folly” of—web developers who build with XHTML 1.0, a stable W3C recommendation for nearly ten years, and one that will continue to work indefinitely. — 7 July 2009
  • XHTML DOA WTF: The web’s future isn’t what the web’s past cracked it up to be. — 2 July 2009

This page has been translated into Spanish language by Maria Ramos from Webhostinghub.com.

Filed under: HTML, HTML5, Markup, spec, Standards, State of the Web

132 Responses to “HTML 5: nav ambiguity resolved”

  1. msikma said on

    This did clear up the spec’s description of <nav> considerably, but it’s like you said: the issue of extensibility is not addressed. This will be a problem in the future, especially when using multiple <nav> elements; <nav role=”main”> for Google’s site map generation, <nav role=”blogroll”> for the XFN, et cetera.

  2. msikma said on

    I should add that at this rate I doubt there will ever be enough momentum among critics to force a major spec change.

  3. simon r jones said on

    i can easily see how the nav tag feels a little too simple. At my agency we use a variety of standard DIV ids for things like site-tools (i.e. logout, search), nav-primary, nav-secondary, nav-breadcrumb, etc.

    However, if something like HTML5 is ever going to get off the ground I can also see why it needs to keep simple to ensure it’s accepted. My ways of doing things won’t be the same as someone else’s, just as long as there is some way of extending things (i.e. role, id or class attributes) I’m sure things will work out fine.

    Thanks for these posts explaining things!

  4. Jeffrey Zeldman said on

    However, if something like HTML5 is ever going to get off the ground I can also see why it needs to keep simple to ensure it’s accepted.

    That makes sense to me, too.

    A combination of simple, universal elements plus an extensibility mechanism would be perfection. Although I also think we’ll be okay if we “extend” HTML 5 the way we currently “extend” XHTML, e.g. nav class="site-tools".

  5. Seth said on

    It almost feels like we’re saying “Rather than have variables that we can name anything let’s come up with a few standard variables that will always mean the same thing”. Just because every site today has a navigation doesn’t mean we should create a tag for it. Hell at one time a lot of sites had things that blinked on them…guess that’s reason enough for a blink tag. :)

    In my opinion I think the majority of HTML 5 tags are just going to add to page size rather than truly benefit the web. I can see from an OCD standpoint they are nice because everything will be very clearly labeled, but it honestly already makes me think very much inside the box.

  6. bruce said on

    These small ambiguities pop out as a direct result of actually trying to use the new language.

    Reading the spec, I’ve been nodding sagely and absorbing the info “yeah there’s a nav tag, great” and moving on. But actually trying to work out whether you can have nav in the header, as a sidebar and within blogposts really made me look hard at the spec.

    A similar debate I’ve been having which might be of interest to minutiae fans is the overlap between figure and aside with particular reference to pullquotes. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020710.html

    It’s one reason I’m trying t0 encourage people to try using HTML 5 on personal sites and report back to the working group if there is an ambiguity or grey area. (Of course, I’m lucky enough to have an employer who pays me to muck around with markup and specs.)

    There is still plenty of time to influence the spec and the working group is actively soliciting fresh eyes to review the spec:

    The plan is to see whether we can shake down the spec and get rid of all the minor problems that have so far been overlooked. Typos, confusion, cross-reference errors, as well as mistakes in examples, errors in the definitions, and major errors like security bugs or contradictions.

    Anyone who helps find problems in the spec — however minor — will get their name in the acknowledgements section.

    You don’t really need any experience to find the simplest class of problems: things that are confusing! If you don’t understand something, then that’s a problem. Not all the introduction sections and examples are yet written, but if there is a section with an introduction section that isn’t clear, then you’ve found an issue: let us know!

    http://blog.whatwg.org/help-us-review-html5

  7. Ben said on

    The new tags are not meant to just ease the developers life but to also provide better detail to screen readers and the like regarding what type of content is contained within a given element. Seth, using your reasoning we should replace all tags with the tag :). I am also unsure how HTML 5 elements are going to add page size.


    becomes:

    Not to mention the multimedia elements, that’s really going to simplify things. Not attacking you Seth, just don’t get your reasoning is all. Cheers!

  8. Ben said on

    oops, my code was stripped out:

    becomes

  9. Ben said on

    Ok, I give up.

  10. Luke said on

    I remain absolutely baffled as to what problem these new elements solve. Could well be my own ignorance. Anyone want to have a stab at filling in the blank here:

    “I wanted to do _______ but it is very hard/impossible without a element”

    Please? Thanks.

  11. Luke said on

    uh, element. Code tag fail :\

  12. Luke said on

    nav. n a v. nav. comment attempt fail :\

  13. Tim Wright said on

    In response to the Bruce Lawson quote: a table of content is actually not classified as “navigation”. The HTML5 spec points out that the “header” element should be used for something like a table of contents…. I’ll look for the link… got it: WC3 HTML5 Spec – Header Element

    The header element represents a group of introductory or navigational aids. A header element typically contains the section’s heading (an h1–h6 element or an hgroup element), but can also contain other content, such as a table of contents, a search form, or any relevant logos.

  14. Peter Gasston said on

    Something that I haven’t seen addressed yet is how the new HTML5 structural elements overlap with WAI-ARIA roles; isn’t <div role=”navigation”> as good as <nav>? It can be styled just as easily (div[role=’navigation’ {}), makes as much semantic sense, and uses less markup.

    Or is it expected that we combine the two – <nav role=”navigation”> – ?

  15. Tim Wright said on

    maybe <nav role=”primary navigation”> and <nav role=”secondary navigation”> since “nav” kinda already signifies navigation.

    html5doctor is using the role attribute, I think it’s a great idea.

  16. Tim Brown said on

    Here’s to those little actions that a leader takes to make something great. I’ll share something else about Ian.

    In 2006, I found a two-year-old post about HTML5 and emailed Ian to ask why I hadn’t heard more about it at the time. As you can imagine, he’s a busy guy. But he wrote back to me, explained that what I’d found was old but that HTML5 was progressing, allayed my concerns about XHTML vs. HTML5, and helped me find more information.

    The fact that Ian spent his valuable time helping to teach me — well, it’s the kind of thing you don’t forget. It’s the kind of thing you try to imitate. So I think about that when I check my email.

  17. Shane McCarron said on

    I think that the mistake the HTML5 community is making here is attempting to introduce elements to convey semantics. As another poster rightly mentions, it is very difficult to predict the future. If the intent is to permit screen readers and other assistive technologies to better serve their users, I suggest that the WAI-ARIA methods coupled with the Role Attribute as defined by the XHTML2 Working Group is a much more scalable way to go.

    The Role Attribute Module provides an extensible way to annotate areas of the page. The Assistive Technology community has embraced the use of @role and it is included in the WAI-ARIA document. HTML5 should, instead of inventing new stuff locally to provide for accessibility, bow to the experts.

  18. bruce said on

    Tim, I think you’re mis-reading the spec. A header may contain a table of contents. It may also include a search form. It doesn’t mean that a search form should not be marked up with a form element any more, and neither does it mean that a TOC may not be marked up as nav.

    Neither does it mean that search forms or TOCs may only ever appear in a header, only that they may.

    Peter – Steve Faulkner has a cross-reference of how HTML 5 and ARIA landmarks overlap http://www.paciellogroup.com/blog/?p=106

  19. msikma said on

    Ironically, the example tags on this blog’s comment form are all in uppercase.

    However, if something like HTML5 is ever going to get off the ground I can also see why it needs to keep simple to ensure it’s accepted.

    Which calls into question the idea of adding elements like <nav> in the first place; wouldn’t it be more simple to simply use <div> (or <ul>, depending on the context) and a semantic attribute such as “role” or “structure”?

    I’m not saying it necessarily is, but I’m just not convinced it isn’t, especially if proper extensibility is to be added to the spec.

  20. Neal G said on

    Perhaps by having new elements such as NAV, browsers will be able to take advantage of these new elements and allow users to view them differently if they so choose to.

  21. Luke said on

    The idea of pseudo-standardizing these new elements will inevitably fail simply because they are, by definition, too vague to have any practical application.

    A link is a thing. An image is a thing. A video (hooray for that, in theory) is a thing. A paragraph is a thing.

    Beyond their inherent function, you can crawl links, search for images or videos, and parse paragraphs.

    Nav, header, footer, whatever – these are abstract collections of things. A link is a link is a link is a link. An img is an img is an img. A “header” or a “nav” can be used in wildly different ways, which instantly makes them redundant.

    If you don’t use an anchor, you don’t get a link. If you don’t use an img tag, you don’t get an image.

    If you do or don’t use a nav, header, footer, you don’t get… ?

    Well, what? The warm fuzzy feeling that your markup is ever so slightly more “proper”?

    It’s not like the top of your web page is suddenly not going to appear if you don’t use the header tag. And that means no one will ever use it (beyond nerds in a markup properness pissing contest).

    These new elements seem like an exercise in markup pedanticism written by spec authors for spec authors.

    They will be of interest to 0.000001% of markup authors anywhere – the kind of people who are genuinely interested in reading thousands of words on the “proper” way to use these elements together, because their primary aim is ‘properness’, not any real problem.

    There’s no cost if you don’t use them. There’s no benefit if you do. Adding classes/ids/roles to “extend” them simply takes us back to square one.

    There are good parts about HTML 5. These new elements are not them.

    They’re not harmful. They’re just pointless.

    The community’s time would be far, far, far better spent on real problems, like true separation of presentation and content (remember that?), extensible markup as has been argued, and a decent CSS layout system (for starters).

    Perhaps the only thing more pointless than these new elements is any more time discussing them. If they go in, so what? Nothing is really gained, but nothing is lost.

    The only thing we have to lose from here in is time which could be better spent on more worthy issues.

    Maybe we should just ignore them and focus on practical aspects of the spec, or that little ol’ thing we call CSS?

  22. Ron Adair said on

    at one time a lot of sites had things that blinked on them…guess that’s reason enough for a blink tag. :)

    I’d love a dedicated blink element – my personal stylesheet would look like this=

    blink { display: none; position: absolute; top: -15000000000em; /*DIE BLINK, DIE*/
    }

    But really, as was stated earlier a dedicated NAV element would help screen readers gain more clarity on the site’s general navigation. Additionally, I imagine it would help clean up the code, if not standardize it a bit. Right now it’s a mixed bag when it comes to the navigation structure on the great www. DIVs, SPANs, LIs, TABLES…I’d argue that a dedicated NAV structure could be as fundamental as the BODY/HEAD structure.

    I realize in the future most sites may bypass navigation as we know it for some hi-tech form of eye tracking, etc. That’s a big “maybe” in my mind. But for now, for the few who want to think so entirely out of the box that a centralized, structured navigation doesn’t fit them – fine, break the rule. There won’t be any guys in suits that come knocking at 3am. For the rest of the world, NAV works for the better good.

    Finally, a NAV element would add to the page both structurally and semantically. You can’t say that for a blink element. Consider new elements LEFTCOL & RIGHTCOL. Sure, it’s common to have a two column layout. In this case a series of COLUMN elements might seem like the same thing a NAV element – extra markup. But COLUMN elements wouldn’t give semantic value in this instance. LEFTCOL & RIGHTCOL wouldn’t offer any clues as to the hierarchy of the page. And who cares if the content is in a column.

    I see NAV as a simple addition to the spec, and I’d be willing to bet that most will use it regularly.

  23. Luke said on

    Also, can I just call BS on the “oh it will help screen readers” line?

    This is just markup pedanticism hiding behind noble sounding intentions simply because it has nowhere else to hide. But it’s just using the needs of the blind to throw dust in our eyes, which is pretty shameful when you think about it.

    Have screen reader users been clamoring for the use of a footer tag? Have they been suffering because ‘sections’ weren’t arbitrarily delimited?

    Please.

    If we actually want to help the vision impaired, great! Find some standard way of helping them in real, practical, demonstrable terms.

    But don’t throw out this baloney that we are really helping the less fortunate through our benevolent gesture of markup pedanticism.

    This is markup nerds trying to scratch an itch that only they feel.

    Even the blind can see that.

  24. Ted said on

    HTML? XHTML? version 4 or version 5?

    How about forgetting it all and just use flash? No need to get agreements about tables and version changes. It all gets dictated and done by Adobe. Committees just don’t work.

  25. dzone.com - New links said on

    [...] 2 0 [...]

  26. Luke said on

    One final thought on screen readers:

    What if we all got together with the screen reader companies and decided that a class “x-sr-nav” (x being arbitrary, sr = screen reader, nav = this is primary navigation) indicated navigation that could be skipped (or easily found, or whatever).

    They implement it. We use it. In x/html 3/4/5 whatever. It’s not hard. It doesn’t require browser support or spec author approval. It solves a real problem right now.

    Are we interested in that, or are we interested in pedantic markup pissing competitions?

    Yeah, thought so.

  27. Intelligent Design » Website Navigation Fundamentals said on

    [...] Soon after this post was made Jeffery Zeldman made a post on HTML 5 that will enable a higher level of semantic code for [...]

  28. Tim Wright said on

    @bruce right, I think it’s left intentionally ambiguous for developer interpretation and changes in future usage, but I think the hinting at what types of parent element we should be using help a lot with clearing up some confusing.

    I agree that there are semantic issues coming down the line for HTML5. I actually really dislike the use of “header” and “footer”. With revamping such a massive language there are going to be some natural shortcomings, we can’t address all the problems with a single version upgrade. Progressively building and seeing what works over a long period of time will prove to be very effective. I don’t think it’s worth further delaying usage to change the element names.

    The real value of HTML5 lies in in API

  29. Ian Hickson said on

    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.

    Also, HTML5 has a whole host of extension mechanisms including all of HTML4′s:

    - Authors can use the class attribute to extend elements, effectively creating their own elements, while using the most applicable existing “real” HTML element, so that browsers and other tools that don’t know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.
    - Authors can include data for scripts to process using the data-*=”" attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.
    - Authors can use the mechanism to include page-wide metadata. Names should be registered on the wiki’s MetaExtensions page.
    - Authors can use the rel=”" mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki’s RelExtensions page.
    - Authors can embed raw data using the mechanism with a custom type, for further handling by a script.
    - Authors can create plugins and invoke them using the element. This is how Flash works.
    - Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.
    - Authors can use the microdata feature (the item=”" and itemprop=”" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.

    “HTML5 should support a way for anyone to invent new elements”

  30. Michael Kozakewich said on

    Major Déjà Vu! You didn’t re-use any comments? I’m pretty sure I read 44670 and 44671 the other day…

    Anyway, what some people haven’t yet pointed out is that most developers already have a div grouping their headers and footers, so the header/footer tags just make it more semantic. It’s not something that has to be used, but makes sense to use if you’re grouping header elements together.
    Likewise, you might never use a p tag. Just set a margin and padding on your divs. A few simple classes would eliminate your need for h1 (h2, etc…) as well as ul, ol, and li.

    So it’s all about taking something we use a great deal, and making it easier. As long as you don’t need to use them, you can still think outside the box.

  31. John Allsopp said on

    “when the future comes we can just fix HTML”?

    Ian, you seriously think that?

    HTML 4 is 10 years old now. Earlier attempts to standardize HTML by the likes of TimBL, Dan Connolly and Dave Raggett in the mid 1990s, when the web was a far far simpler place failed, and the first attempt at the next generation of HTML is DOA (XHTML2), 10 years later.

    HTML5 is years from being complete (and frankly the talk of “lots of HTML 5 currently being supported in browsers” is a stretch at best).

    We CAN’T just fix HTML every 10-15 years with a 5-10 year process. This is the only shot for a generation. That is a huge responsibility not just for those directly responsible for the specification, but all of use who take more than a passing interest in these issues.

    Is the W3 TAG prepared to endorse the fundamental philosophy that “when the future comes we can just fix HTML”? Is so, I’d argue that’s an abdication of their mission to “lead the web to its full potential”. If not, then I think the TAG needs to exercise some leadership.

    Re extensibility: a grab bag of essentially pseudo-extensibility mechanisms does not address the issue. Particularly when the profile attribute of the head element, which can be used to formalize a vocabulary as evidenced by GRDDL has been removed. It would appear that there is a strong active aversion to the whole issue of extensibility at the WHATWG, despite this being not only clamored for, but implemented by large numbers of developers via the class attribute for a decade, with microformats a particularly successful example . However, this method is inadequate to create genuine extensibility (the class attribute is specified as being for “general purpose processing by user agents” in HTML 4, and “any value … [with developers] encouraged to use the values that describe the nature of the content” in HTML 5).

    The single biggest challenge is that there’s no common vocabulary that developers can use for common patterns, and which browser developers, extension developers and others can then leverage to provide greater functionality within the browser – whether these be data extraction services as we’ve seen with microformats, navigation aids based on the navigational aspects of the page and so on.

    In particular, can you explain for instance the WHATWG’s apparent extreme aversion to the role attribute? It’s a W3 working draft in ARIA. It provides a superset of the current HTML5 structural semantic elements, it is backwards compatible with IE7 without JavaScript, it doesn’t conflate the role of an element (elements may play multiple roles) with its kind. For example, a list of links is an extremely common markup pattern for navigation on a web page – the element IS a list, this LIST plays the role of navigation (and possible other things). The HTML role attribute makes existing markup easily “upgraded”. HTML 5 requires wrapping all these lists in nav elements (and as discussed below, possibly removing them from headers and footers where navigation is frequently found, and from which sectioning content, including nav elements are forbidden).

    And yet, there seems to be a steadfast resistance to role. Meanwhile we get elements like hgroup parachuted into the specification, so poorly motivated or explained that I’ve decided to simply leave it out of the detailed chapter on HTML5 I’m writing.

    To get back to Jeffrey’s original point in the article – as I waded deeply through the specification, narrowing my focus largely to the new “semantic” elements like section, article, header, footer, and so on I discovered many ambiguities, poorly explained features, and baffling containment rules like footers may not contain sections (despite a glance at any number of real world examples which show that they frequently do), headers can’t contain sectioning content (which includes navs, yet how many page headers contain navigation of one kind or another?), near byzantine complexities (word processors, page layout applications and so on have been generating complex Tables of Contents for huge books using nothing more than heading levels for decades, and yet we’ve now got this complex sectioning model, that no one in the “real world” seems to remotely have been clamoring for).

    The HTML 5 specification has an enormous amount of work to be done on it – not simply “minor corrections” as the WHATWG blog recently called for help with.
    http://blog.whatwg.org/help-us-review-html5

    “Work on HTML 5 originally started in late 2003″
    http://www.whatwg.org/specs/web-apps/current-work/#history-0

    That’s coming up to 6 years.I’m afraid, IMHO, HTML 5 after all that time is a mess.

    What’s the goal of HTML 5? Try finding out. There’s no mention in the spec, and in the FAQ, a reference to “enhancing (X)HTML to more adequately address Web applications”. I’m really not sure that nav, section, article et al, and the sectioning models, to name just two areas of innovation address this goal at all.

    A project without clear goals will almost certainly turn out to be a mess.

    This is not something that too many people have been prepared to say, so I might be completely wrong. But I invite anyone who wants to argue that assertion to spend some time in the specification. Try turning some non trivial sites into HTML 5 based markup. Try working out when something is an article, and when it is a section. Why can’t a header include a nav element? Or a footer sectioning content? Such byzantine rules not only contradict real world examples, but are bound to ensure that errors abound as people break these rules.

    There’s recently been much jubilation that XHTML2 is dead. But many of the legitimate criticisms of XHTML2 can also be laid at the door of HTML 5. And many others, particular to the specification itself can also be leveled. It’s time to address these.

  32. Ian Lloyd said on

    Just wonderin’ …. could Joe Clark perhaps just write an article for ALA and title it ‘To Hell with HTML5′. That ought to do the trick. Worked a treat before ;)

    Thanks you all, my work is done.

  33. html5 is a mess | For A Beautiful Web said on

    [...] Elsewhere: html5 is a mess [...]

  34. Dale Cruse said on

    [...] Cruse Link Post Reading: HTML 5: nav ambiguity resolved Even after more than a decade, Mr. Zeldman is still my #1 go-to web reference. 0 notes [...]

  35. Max Design - standards based web design, development and training » Some links for light reading (14/7/09) said on

    [...] HTML 5: nav ambiguity resolved [...]

  36. Rob said on

    I can’t help but look through some of these comments and think people are saying, “But I don’t wanna!” Or maybe they are just old men who are too tired.

    I’m 57 and I’m not too tired to use HTML5.

  37. Ian Hickson said on

    John: I encourage you to send this feedback to one of the mailing lists listed in the specification, so that it can be properly taken into account. A blog’s comments section is hard for me to keep track of in the HTML5 issue-tracking mechanisms. If you don’t want to mail it to a list, feel free to mail it to me directly at ian@hixie.ch so I can track it that way.

    Jeffrey: Incidentally, the WHATWG doesn’t have a chairman; I’m just the editor. Sam Ruby and Chris Wilson are the chairs of the HTMLWG. Those are the only “chairman” positions in this effort.

  38. Billee D. said on

    Man, talk like this is exciting. It nice to see that HTML 5 is really starting to be discussed more often. :-)

    I am excited at the possibilities that HTML 5 will offer. It nice that we are starting to discuss it more. This can only help to increase adoption rates. Just talking about it at all is huge step in the right direction and it’s nice to see the different working groups listening to the community. It’s not going to be an easy transition.

  39. Niels Matthijs said on

    I think the new nav element is just more than enough for now. We could indeed start making up roles with fixed names, but looking at the comments people are already messing up terms.

    It’s hard to define what primary navigation is and what secondary navigation is. There’s a main nav and sub nav, but also navigation to site-related but not content-related pages (like sitemaps, privacy policies, faqs and such). Which is still pretty different from inpage navigation or breadcrumbs.

    Trying to come up with a good role for any of those is just plain hell, seeing as how debates go on between people involved in the specs. I’m pretty content with the way we “extend” our html now. The nav tag allows us to improve our code semantically, the rest is still up to the coder.

    And if there are still people who fail to see the importance of the nav tag, it’s probably best to try and fix that first before going for a standardized extension model.

  40. oli said on

    @Zeldman—a lot of the spec doesn’t necessarily make sense for authors, which is pretty standard for W3. I suspect this is because it’s primarily written for implementors (browser makers etc), and also because the people writing it are primarily spec writers, not educators. However as demonstrated in your <nav> example if anyone can suggest a better way to write things, please let WhatWG know.

    @luke—the benefit of the new sectioning elements are document outline generation for free, and explicit in-page and site navigation. These new elements are also formalising some the common extensions authors are currently making using class/id. Finally, there’s more to accessibility (and assistive technology) than screen readers. Bonus points for ranty-ness though ;-)

    @John Allsopp—I think the current landscape is significantly different from the 90’s. Noticeably browser makers are in general implementing W3 specifications (and correctly), and most of the major players are active participants in the process. The HTML5 specification defines error handling. Authors are now more aware of industry best practices. Finally the process for specifying HTML5 is quite different to previous HTML specs. I (optimistically) think these things will help future updates to HTML be carried out more quickly than they previously have.

    Ian mentions that there are already several extension mechanisms (class/id, rel, meta, data-*, microdata), and that ‘new element’-style extension without Microformats or WhatWG-style steering is not beneficial. I know your views on this, but I wonder if you can give some examples to illustrate how role would be better than the current proposed mechanisms, to make it easier to understand. For example, how would role have helped solve the shortcomings of HTML4 over the last ten years?

    Finally, currently <header> and <footer> both disallow descendant <header> or <footer> elements. However, while sectioning and heading elements are also not allowed in <footer>, they are allowed in <header> (including <nav>). If a page header needs to contain sections with their own headers/footers, or a page footer needs to contain sectioning or heading elements, then in this situation a <section> is more appropriate, according to the current WhatWG spec. I’m interpreting header as titling and introductory content, and footer as additional or navigation content, to a section. I’m guessing you’re viewing them more as print-style devices, based on their location.

    I wrote some more here, should anyone be interested…

  41. Don Ulrich said on

    Ian sez: “It’s more important that HTML caters to the present than to the future.”

    HUGE FAIL Ian: What happens to the documents we create now that need to be read in the future? So in other words HTML is no longer archival. That it is a temporal mode to express a database? That is just B.S. Markup of any kind should represent the expression of natural language. Natural language should not be formatted so that the liturgy becomes more important than the expression. If we do that, what you are expressing becomes secondary to the markup.

  42. Daily Links for Tuesday, July 14th, 2009 said on

    [...] HTML 5: nav ambiguity resolved – Jeffrey Zeldman Presents The Daily Report [...]

  43. Julio Loayza said on

    John Allsopp:

    Amen!!!

  44. Joe Clark said on

    lloydi, Joe Clark pretty much does not give a shit about HTML5, if you want the truth. And anyone who thinks it really is a group effort hasn’t been paying attention.

  45. Jeffrey Zeldman said on

    To those who are debating here lucidly and respectfully, I thank you and our community thanks you. Keep it flowing. Many of us who are silent at the moment are urgently following along.

  46. Tim Wright said on

    I have a feeling that we may be focusing too much on the negative here. Whichever side of the debate you’re on with new elements, there have been some oversights to the real point of HTML5. Maybe they dropped the ball on some of the definitions of the elements (which is easily dealt with by just writing more), but the API is pretty amazing.

    It’s not fully supported yet (and who knows when it will be), but it’s got some great stuff in it like geolocation, drag and drop, media embedding (audio & video) and application cache. If you get a chance to look into Google Wave, it does a great job of showing the power HTML5 has (in conjunction with JavaScript).

    It wasn’t until I really read through the spec that I saw the benefit in this markup language. There’s very little benefit in using a new element, I was perfectly content in using some top-level divs, but the API, that’s what is going to further the Web. And I’m really looking for to getting my feet wet with it.

    If we learn and read all we can over the next year or so (how ever long it takes browsers to catch up) we’ll be all more prepared when the gradual switch does come. HTML5 isn’t going to please everyone, and I think the good massively outweighs the bad, and we have a long time to prepare for the inevitable growing pains that come with a new syntax.

    my2cents

  47. Alex Stillwagon said on

    If I may speak as a completely “small name” web designer and developer. This IS a mess. I’ve worked the last 9 years to get where I am today. And I’ve worked have to gain knowledge and experience with design, code, standards, back-end systems, css, xml, and etc,… (Just like the many other designers/developers here).

    I have yet to see how any of these new rules are in anyway going to make it easier to develop websites. (And, no I have not been taken in by the “wonderful”Video tag.) None of the standards (haha, the irony) of HTML5 make it one bit easier to code a good site that is easy to understand. In fact, as a regular-guy developer, I’m looking at this mess thinking about how I now have to relearn most of the stuff I know to code a website. And none of it addresses any of the coding issues I face everyday.

    Moving to something as unnecessarily complex as HTML5 will turn out to be, and it will be extremely complex, is a move in the wrong direction. (HTML4 and XHTML1 are already dang complex) Ever heard of K.I.S.S.? Isn’t the web already enough of a hogdepodge of un-semantic, old – new, good – bad, code already?!?

    From my limited perspective, HTML5 is not nearly the leap forward out of the mire into clean, clear water that I want and need as a developer. It is a big jump from one muddy, stagnant puddle to another one. I mean, really, does anyone here believe that when HTML5 is finally mainstream any of us will be saying how much easier, simpler, and clearer our code and lives have become compared to XHTML1?

    The W3C recommendations look more like U.S. Tax Code that any real guide on the best practices for site construction. One of the main areas that the W3C goes wrong in is in letting browser makers have any place at the table. Before anyone lets me have it in the further comments, consider this: have W3C standards made it easier to achieve Cross-Browser compatibility? Hardly! And why not? Answer: MS Internet Explorer. With 70% market share they can do what ever they want to and the W3C is impotent to correct their extremely poor implementations. And they refuse to correct them too. (Hey, Microsoft! Send out a mandatory update for IE 6 that makes it render CSS correctly! Duh!)

    And that is the crux of the problem:

    Their is too much information for any reasonable person to be able to handle and remember at any given time AND be able to creatively employ designs and User Interactions as the same time.

    (Do a search for web design books, if you doubt it. There has been more effort put into writing and reading books about what the “standards” mean than effort put into making the standards understandable in the first place! By a ratio of about 1,000,000,000:1.)

    Semantics is great but it is not the main purpose of the web. Conveying information is! I have serious doubts that HTML5 will do anything but make it harder to do that effectively in a consistent manner.

    Life as a web developer just gets more complex each day. Each area of web design / development gets more complex and requires more specialization. I just don’t see how it is a good thing for the future of the web to make it harder still to create an information conveyance tool that is meaningful and creative that works reliably across multiple platforms, devices, “user-agents”, and the boundaries between people.

    In my humble opinion.

  48. John Foliot said on

    @ oli “For example, how would role have helped solve the shortcomings of HTML4 over the last ten years?”

    Uhm… ARIA? (It ain’t perfect, but damn it’s pretty darn good for a retrograde patch; plus, what ever happened to not re-inventing the wheel?)

    “…the benefit of the new sectioning elements are document outline generation for free, and explicit in-page and site navigation. ”

    Uhm…

    Chapter 1: Week 1
    The First Day
    The Second Day
    The Third Day
    Chapter 2: Week 2
    The First Day
    The Second Day
    The Third Day

    …plus, Adaptive Technology such as Screen Readers already use headings for inter-page navigation, so implementing this type of functionality inside of browsers should not be that difficult to do; again, what ever happened to not re-inventing the wheel?

    Then there is the whole issue of regressive accessibility, from the contentious debates surrounding the @alt attribute, @headers/id, @summary, etc., the total lack of accessibility of canvas, issues with video/audio, and much, much more.

    So, like Muldar, I want to believe, but at the same time remain very skeptical of the current flying saucer that is HTML 5.

  49. Julio Loayza said on

    Well, in my opinion John Allsopp said it all in his last comment. But, what I wanted to say (before reading his fantastic comment) is that I also think that adding real and standarized semantic to actual elements using role, or any other new similar attributes, is a solid and global solution that not only really solves the same real problems (and some other imaginary ones) that are intended to be “solved” with HTML 5 new tags, but also is a backwards compatible and more extensible solution. More extensible because, as said before, the arriving of new role properties in the future would always be more backwards-compatible (fordward-compatible) that the arriving of completely new elements.

    It is so clear for me that I don’t understand it in other way. The only reason that I find for that pig-headedness of ignoring so valid solutions like role in the HTML 5 thing is that, in the end, the whole thing is a question of egos: “I was who reinvented HTML! HTML 5 is my creation, man!”

  50. oli said on

    @Don Ulrich—I don’t understand how ‘not catering to the future’ prevents current documents from being archival. All browsers can still render HTML1 adequately. I’d place a hefty bet that browsers of the future (10+ years) will render HTML5 adequately too. Backwards compatibility is a market (and therefore browser) requirement (cf: XHTML2).

    @Alex Stillwagon—HTML5 is much closer to what you already know than you think; because backwards compatibility is a primary goal, relearning is mostly unnecessary. Some rethinking maybe…

    I’m guessing you’re basing your impression of HTML5’s complexity on the main spec, which is written for implementors. Have a look at the W3C author’s version, or use “Hide UA text” on the WhatWG version. Unfortunately with increased capability comes increased complexity, so unless you’d like to go in the opposite direction and remove elements I don’t think it’s humanly possible for HTML5 to be simpler than what came before.

    Browser makers get to decide what actually gets implemented, and unfortunately nothing’s going to change that. If you ‘exclude them from the table’ they’ll just go do their own thing—that’s where WhatWG came from.

    It’s not possible for MS to do a mandatory IE6 update because many company intranets (and the whole of South Korea, ouch!) depend on ActiveX or IE-only code. Here’s hoping everyone learned a lesson from this one huh.

    While I’m sure we all despair about keeping up to date, that’s unfortunately just part of our industry. The spec creators are writing primarily for browser makers, and the spec is the way it is (ie occasionally unintelligible) because it has to be explicit for those programmers. However I’m sure good people are on the case writing easy-to-understand books about all of this, and that’s a good thing.

    “Semantics is great but it is not the main purpose of the web. Conveying information is!”—I’d actually argue that semantics also conveys information, and more semantic options is a good thing.

    Finally, for me the most important part of your comment; what are the coding issues you have today? Tell WhatWG and maybe you can get them addressed…

    @Julio Loayza—again as I asked John, can you give some examples of how role would have solved eg problems with HTML4, or where the current HTML5-proposed extensibility methods are inadequate? I’m not saying this to be an ass—I sincerely want to know so I can find out more. From my perspective the extras that HTML5 provides are good enough for everything I can imagine, and there are rumors about incorporating RDFa into HTML5, so I want to know what I’m missing. I agree there’s an infinite number of things I can’t imagine, but I suspect that role won’t be able to cope with all of them either ;-)

  51. river brandon said on

    wow, what a great debate. this is really the meat of it. as another “small-name” web designer, i am squarely caught in the middle as far as where i come down in this discussion. i wholeheartedly support extensible systems that are based on sound logic, and provide a good foundation for future things we haven’t thought of yet. at the same time, we need good, semantic markup that works for the present.

    predicting the future is a tricky business, from what i’ve heard. yet that can be an argument for a structure, or framework, that is flexible for the future. i was at aea boston recently, and i seem to remember hearing “design systems, not web sites”. seems like we’re talking about designing a system here, and the concern i hear from allsop is that html5 is looking more like a site than a system. i share that concern, as well as the desire for some great new stuff to use now.

    i hope the two (or more) sides can come together and “get real” in such a way that we can have a flexible, modular system that keeps possibility open for the future, but doesn’t take break what we already have or take another decade to realize. keep up the good work, all.

  52. Survivor: W3C | Bb RealTech said on

    [...] "Ian, you seriously think that?" John Allsosp responds to Ian Hickson's statement of "when the future comes we can just fix HTML." [...]

  53. Ian Lloyd said on

    @Joe, I guessed as much ;-) I was, of course, referring to the changes to WCAG 2 which seemed to come about not long after your article on ALA ‘To Hell with WCAG2′. But you know that’s what I’m referring to (just clarifying for others who might not have got the reference).

  54. SimpleBits ~ John Allsopp said on

    [...] —John Allsopp [...]

  55. Tony D said on

    First, I’m really excited about the fact that there is even change happening. Playing with new markup options and bleeding edge CSS features in nightly browser builds reinvigorates and re-excites me about what I do. And, I think there are some great things in the HTML5 Spec. Canvas, for one. Better media (video, audio) embedding for another.

    However, I can’t help but worry about how document focused much of this is. I work as much as a web application developer as anything else, and I think the kinds of super rich applications that represent the cutting edge of our field are not really planned for in the spec. I’m pretty pragmatic about my markup when it comes to application development, but I also really value semantics, and I think many of semantic problems the current spec solves are yesterday’s rather than tomorrow’s. Perhaps I haven’t spent enough time reading and using the stuff from the working draft. I just want to write markup that makes as much sense with experiences and interactions as with documents.

  56. John Allsopp said on

    Oli,

    “examples of how role would have solved eg problems with HTML4, or where the current HTML5-proposed extensibility methods are inadequate”

    I think a simple but profound one is nav. Lots of things on a page might play the role of navigation. Now, if the only method of articulating the roles an element plays is via the name of the element, then

    1. elements may only play a single role (well, they can play multiple roles but only one role can be articulated in HTML5)
    2. elements can’t be anything other than their role

    In practical terms, let’s look at how navigation is very very commonly marked up today – as a list of links.

    With HTML5, we now have to wrap this list in a nav element. But with role, we can simply say

    (for instance)

    So, I think the present situation is much less adequate than role.

    BTW, using role is backwards compatible to IE7 – we can use role attributes, and use the attribute selector to select and style elements based on role back to their – no JS required. And, there’s even a simple HTML/CSS workaround for IE6 and older – use parallel class values for styling – class=”nav”.

    When Ian Hickson was recently asked about the philosophies of HTML5 he replied

    “Backwards-compatibility, incremental baby steps, defining error handling. Those are the main philosophies”
    http://www.webstandards.org/2009/05/13/interview-with-ian-hickson-editor-of-the-html-5-specification/

    Well, role is a much more incremental step than adding a swag of new elements. Its also more backwards compatible. So, in the words of the editor of HTML5, this suggestion is more inline with HTML5 philosophies than HTML5′s “solution”.

    I could go on – hope this is a good start

    j

  57. D Bnonn Tennant said on

    @Alex Stillwagon’s “Semantics is great but it is not the main purpose of the web. Conveying information is!”

    I’m not sure if you realize the irony of this statement, Alex. What exactly is it that conveys information, if it isn’t semantics?

  58. John Allsopp (07/09): Oli, “examples of ... — BackType said on

    [...] HTML 5: nav ambiguity resolved on Jeffrey Zeldman Presents from 1 hour ago [...]

  59. IRC logs: freenode / #whatwg / 20090715 said on

    [...] # [08:33] <hsivonen> appeals to the TAG even: http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-44699 [...]

  60. Henri Sivonen said on

    This will be a problem in the future, especially when using multiple <nav> elements; <nav role=”main”> for Google’s site map generation, <nav role=”blogroll”> for the XFN, et cetera.

    If user agents don’t know about role=blogroll, it is no different from class=blogroll. If you want user agents to know about role=blogroll, some speccing and coordination is needed.

    Something that I haven’t seen addressed yet is how the new HTML5 structural elements overlap with WAI-ARIA roles; isn’t <div role=”navigation”> as good as <nav>? It can be styled just as easily (div[role=’navigation’ {}), makes as much semantic sense, and uses less markup.

    <div role=”navigation”> is as good as <nav> to the same extent <div element=”h1″> is as good as <h1>. Moving the element name to an attribute value was invented in the SGML days. It was called Architectural Forms. It didn’t catch on then, but it keeps being reinvented as microformats, ARIA, microdata, etc. I’d argue that it’s nicer to write <nav> and nav {…} than to write <div role=”navigation”> and div[role=’navigation’ { … }. Other than that, there isn’t a difference really. (Except to the extent that ARIA is only supposed to affect AT behavior and not visual UAs whereas HTML5 features are supposed to have an effect on all media, so in theory it would be wrong for Opera Mobile to look at role=navigation but OK to look at <nav> for generating scrolling shortcuts. Of course, if the theory turns out to be bad, I’m sure the theory will be ignored in due course.)

    If you do or don’t use a nav, header, footer, you don’t get… ?
    Well, what? The warm fuzzy feeling that your markup is ever so slightly more “proper”?

    Excellent point. I expect you don’t get some shortcuts in a screenreader or in a mobile browser. It’s quite likely that it’s too subtle when authors test with visual desktop browsers, so I don’t have high hopes for useful and correct use of the HTML5 structural elements or ARIA landmarks.

    If we actually want to help the vision impaired, great! Find some standard way of helping them in real, practical, demonstrable terms.
    But don’t throw out this baloney that we are really helping the less fortunate through our benevolent gesture of markup pedanticism.

    I agree that unproven markup features too often get a free pass when you portray them as accessibility features.

    What if we all got together with the screen reader companies and decided that a class “x-sr-nav” (x being arbitrary, sr = screen reader, nav = this is primary navigation) indicated navigation that could be skipped (or easily found, or whatever).
    They implement it. We use it. In x/html 3/4/5 whatever. It’s not hard. It doesn’t require browser support or spec author approval. It solves a real problem right now.

    Indeed, the idea that class isn’t “semantic” but role is somehow semantic is bullshit. The ARIA roles are semantic, because browser/screenreader combinations implement behavior for certain values. class is semantic when microformat consumers implement software behavior for certain values. If you just pull random tokens out of your sleeve and no one else’s software triggers behavior on them, your tokens are as semantically void in a role attribute as they are in a class attribute.

    If not, then I think the TAG needs to exercise some leadership.

    Last week you criticized me for saying allegedly unconstructive things. I’ll just say that it’s more constructive to raise your points in the HTML WG or in the WHATWG than to suggest that another group come in and pull rank over the HTML WG.

    Particularly when the profile attribute of the head element, which can be used to formalize a vocabulary as evidenced by GRDDL has been removed.

    Quoting myself from http://lists.w3.org/Archives/Public/public-html/2009Mar/0087.html :
    GRDDL uses profile for two distinct things:
    1) to authorize rel=transformation to be recognized
    2) to dereference for transformation autodiscovery via profile
    documents that may or may not link to a transformation.

    Point #1 can be addressed by a spec such as text/html authorizing
    rel=trasformation to be recognized as a well-known token without
    profile (i.e. making the processing similar to rel=next or
    rel=canonical).

    I think point #2 (i.e. following your nose with canonical URIs) is a
    design bug due to the scalability problems demonstrated already by DTD
    URIs even though DTD URIs in theory aren’t URIs-as-identifiers but
    URIs-as-locators.
    http://hsivonen.iki.fi/no-dtd/

    In particular, can you explain for instance the WHATWG’s apparent extreme aversion to the role attribute? It’s a W3 working draft in ARIA.

    ARIA is pending integration into the HTML 5 spec. It has been blocked on ARIA lacking the kind of detail on user agent implementation and document conformance requirements that are expected of HTML 5.

  61. Carsonified » 23 Essential HTML 5 Resources said on

    [...] HTML 5: nav ambiguity resolved – A post by Zeldman on the HTML 5 Nav element [...]

  62. BlogoWogo - The Blog Network | HTML 5: nav ambiguity resolved said on

    [...] Read More on Jeffrey Zeldman Presents: The Daily Report… [...]

  63. Segnalibri: 13 luglio 2009 - 14 luglio 2009 - Noi (u)siamo la macchina said on

    [...] HTML 5: nav ambiguity resolved – Jeffrey Zeldman Presents The Daily Report – An e-mail from Chairman Hickson resolves an ambiguity in the nav element of HTML 5. [...]

  64. HTML 5: nav ambiguity resolved – Jeffrey Zeldman Presents The Daily Report - Virb said on

    [...] HTML 5: nav ambiguity resolved – Jeffrey Zeldman Presents The Daily Report [...]

  65. Planet HTML5 said on

    [...] "Ian, you seriously think that?" John Allsosp responds to Ian Hickson's statement of "when the future comes we can just fix HTML." (via Mr. Last Week) [...]

  66. me said on

    I can not understand why the W3C is dropping work on XHTML 2, even if it took them an other 5 years to develop. Now HTML5 is promoted everywhere while the spec is not all that mature. I dare even say that the XHTML2 spec had evolved to a maturity that was nearing completion. OK, there were still some issues there, and it would be hard to convince people to start using it, because of it’s higher technical nature, but in the end (I’m thinking 20 years or so) it would be better…
    But 20 years is a long time, and no company in search for profit works on goals to achieve in a 20-year span. Plus, there is no really money to be made with standards.
    It’s easier to come up with something new and exciting(not standardised), that way you keep total control of what happens with it. We’ve seen it millions of times: DocXML/ODF, JScript/Javascript/EcmaScript, styling properties in different browsers/CSS, XAML/SVG,… Meanwhile a spec like HTML5 doesn’t grow out of testcases and study, but out of what already exists in recent browsers…

  67. HTML 5 and CSS 3: The Techniques You’ll Soon Be Using - Nettuts+ said on
  68. 23 Essential HTML 5 Resources - Programming Blog said on

    [...] HTML 5: nav ambiguity resolved – A post by Zeldman on the HTML 5 Nav element [...]

  69. John Allsopp said on

    Henri,

    this quote is from me, the others in your comment are not, so I’ll address this one.

    Last week you criticized me for saying allegedly unconstructive things. I’ll just say that it’s more constructive to raise your points in the HTML WG or in the WHATWG than to suggest that another group come in and pull rank over the HTML WG.

    Last week I, and I wasn’t alone, criticized you and others (the editor of the officiall HTML 5 FAQ for one) of using snarky, disparaging (not to mention inaccurate) counter-productive language. I don’t think my questioning whether the W3 endorses the philosophy

    When the future comes, we can just fix HTML again. It’s more important that HTML caters to the present than to the future.

    is unconstructive. Not all criticism is counterproductive. I don’t think my formulation was disrespectful, the way in which the language I criticized last week was definitely disrespectful to a great many people.

    but far more significantly, This philosophy is not only not “leading the web to its full potential”, but in fact an abdication of leadership. I’d strongly argue its at odds with the mission of the W3C – to lead the web to its full potential. As you know, the HTML WG has a charter. It’s effectively what allows the WG to work on HTML. This says the mission is “to continue the evolution of HTML”. Evolution is defined as “A gradual process of development, formation, or growth, esp. one leading to a more advanced or complex form”. I think this is at odds with the stated philosophy, and so arguably the work of the group is currently out of charter.

    But, with this telling comment, I think we have got to the root of the problem here.

    If you think the TAG (who I mentioned here as in effect the “board” of the W3, perhaps I should have said “management group of the W3″) and so by extension, the W3, the organization that is the custodian of the web, and is charged with the mission of “leading the web to its full potential” is “another group” that would be “pulling rank” by entering into the issue of HTML 5′s philosophy and direction, then I very much hope this is not shared by others in the WHATWG. This would indicate that the group sees itself as independent from, and in no way effectively part of the W3c. WhatWG has clearly maintained for itself the right to take the HTML 5 spec and continue to develop it under its own auspices should it decide that this is for whatever reason the way it wishes to go forward. Couple the attitude enunciated here with this escape route, and I think we have a very precarious foundation for the development of HTML 5.

  70. 23个HTML 5 的资源汇总 « SonicHtml工作室- PSD转HTML / XHTML,CSS / W3C验证 / 多浏览器支持 / WordPress模板 / Joomla模板 said on

    [...] HTML 5: nav ambiguity resolved – HTML 5 的导航元素 [...]

  71. Jason Grant said on

    If a deeper discussion is to be had over I am sure it would prove to be a bad approach to HTML spec.

    It’s a molecular tag and each one of them is usually asking for trouble, unlike atomic tags such as or which I fully support.

  72. bruce said on

    Outrageous self-link alert:

    HTML 5 is a mess http://www.brucelawson.co.uk/2009/html-5-is-a-mess/

  73. Henri Sivonen said on

    If you think the TAG (who I mentioned here as in effect the “board” of the W3, perhaps I should have said “management group of the W3″) and so by extension, the W3, the organization that is the custodian of the web, and is charged with the mission of “leading the web to its full potential” is “another group” that would be “pulling rank” by entering into the issue of HTML 5’s philosophy and direction, then I very much hope this is not shared by others in the WHATWG.

    My point is that if you have criticism towards HTML5, it’s constructive to raise those specific criticisms in the HTML WG. It’s not nice to call for someone else to bring the message to the group from the position of authority.

  74. Flakerim Ismani said on

    I took two days to review html5, to decide if I can start do sites on it. After some time spend on concept of HTML5 I came to this conclusion:

    HTML 5 WILL NOT STAND 10 YEARS FROM NOW.

    Why? Because does not have anything that today we can’t achieve in html4. Why , tags are so special . Where is difference between adding and expect eye-candy. Really, web 2.0 is so 2005, I just think web what.0 will be on 2020. We are just going so slow with standardization and same time the need is more than that. Its like we are just standardizing the past.

    Today’s machines can handle more than that. I need to define by my self what the structure of my code will look like. It has to be more generic. I don’t know but HTML5 looks to me just rename of to , I don’t see anything special. Its like Windows Updates, that you receive almost daily.

    We want html5 to me Beyond HTML. New logic, new way how browser will think. Not just a reformat of code. Just like you do when you finish coding you application.

  75. Flakerim Ismani said on

    I took two days to review html5, to decide if I can start do sites on it. After some time spend on concept of HTML5 I came to this conclusion:

    HTML 5 WILL NOT STAND 10 YEARS FROM NOW.

    Why? Because does not have anything that today we can’t achieve in html4. Why header, footer, nav tags are so special . Where is difference between and expect eye-candy. Really, web 2.0 is so 2005, I just think web what.0 will be on 2020. We are just going so slow with standardization and same time the need is more than that. Its like we are just standardizing the past.

    Today’s machines can handle more than that. I need to define by my self what the structure of my code will look like. It has to be more generic. I don’t know but HTML5 looks to me just rename of to , I don’t see anything special. Its like Windows Updates, that you receive almost daily.

    We want html5 to me Beyond HTML. New logic, new way how browser will think. Not just a reformat of code. Just like you do when you finish coding you application.

  76. Last Week in HTML5: W3C supplicant of the WHATWG - the root of the W3C Crisis said on

    [...] da Sopp sez:But, with this telling comment, I think we have got to the root of the problem here. [...]

  77. Realidad Aparte » Semántica en HTML 5 said on

    [...] raíz de un artículo de Zeldman se ha generado un debate apasionante sobre la semántica en HTML 5, suscitado en parte por un artículo de John Allsopp en ALA titulado [...]

  78. Ian Hickson said on

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

  79. me said on

    @Ian: you can achieve most of these things through ecmascript, but I think the problem lies elsewhere. HTML5 tries to change the web evolutionary, which means it will take several steps(specs) before you get to your actual goal. Which means we will always be in between specs for years to come. I think a revolutionary step would be harder to take, but faster achieved.
    In XHTML2 I saw that revolutionary step. And If browser-vendors want to extend te posibilities, let them do that in their own namespaces, with their own doctypes or even their own mime-types. We’re trying to create a standard here…

  80. Ian Hickson said on

    I don’t know of any sane way to do any of those in JavaScript, and with the exception of date controls and range controls, I don’t know any way to do them in XHTML2, either.

  81. me said on

    It’s true that the necessary code in javascript looks rather insane, but it is possible though… And also I’m not saying XHTML2 provides those; But you could easily create an other spec to provide those by extending XHTML2, that way those specific controls could even grow evolutionary, while XHTML2 stays the same. Or to put it otherwise: I believe in a very strong foundation, on which you can easily build with all types of building blocks, I hoped for XHTML2 to be that foundation…

  82. Bruce Lawson’s personal site  : HTML 5 is a mess said on

    [...] to deal with. And there plenty of people who aren’t convinced it’s groep effort after all (see http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-44761). But on that subject, I have no opinion, as I know too little about [...]

  83. HTML5 Tips: structral elements, Doctype and ARIA » iheni :: making the web worldwide said on

    [...] has been a lot of discussion around what “major” navigation means (site, section, in page navigation, related links?) and what can legitimately be wrapped in the [...]

  84. HTML5 and The Future of the Web | How-To | Smashing Magazine said on

    [...] article. The spec now says “major”, see the Zeldamn article on nav ambiguity resolved Link [...]

  85. chandichonk said on

    Regarding not being able to put [nav] inside of [header]. This is really silly. 9/10 sites in a css gallery have numerous divs, paragraphs, headings, forms, and lists inside their div#header and/or div#footer.

    Now, usually the height of the div#header in 95% of designs never changes so in those cases the [nav] not allowed in [header] issue wouldn’t bother me as long as it’s possible to absolutely position my [nav] relative to the [header] area even though my [nav] tag is not a child of [header]. Is that possible in html5/css3?

  86. Ryan said on

    What a mess. Seriously now I can see why Microsoft doesn’t even attempt to deal with “web standards”.

    I completely agree with Luke and John. We’re spinning our wheels on pointless stuff here. Instead of creating new tags for such content, let’s select some standard roles that can be implemented extensibly. Then let’s focus our efforts on improving the capacity of CSS.

  87. Jeffrey Zeldman said on

    @Ryan:

    Seriously now I can see why Microsoft doesn’t even attempt to deal with “web standards”.

    Golly, Ryan, where do you get that stuff?

    Microsoft is committed to supporting web standards, as is every other browser maker. Chris Wilson, for many years the lead developer on Internet Explorer, has also served for many years on W3C HTML committees, and has contributed his expertise to CSS and HTML (including HTML 5).

    Have you seen what IE8 can do? Did you know that IE3 was the first browser to support CSS? The support was not complete or perfect, of course, but Microsoft was initially ahead of the pack on CSS.

    Microsoft certainly supports web standards.

  88. John Allsopp about the future of HTML // HTML Five said on

    [...] You can read the entire comment (and the discussion were it came from) in Zeldman’s post about the nav element. [...]

  89. Web Teacher › Useful Links: Open Web Tools, HTML 5 nav, CSS 3 Cheat Sheet said on

    [...] HTML 5: nav ambiguity resolved at zeldman.com is interesting because The Zeldman has the same problem I have with the HTML 5 specs, and also because the discussion that follows is fascinating. Don’t just read the article—read the comments, too. [...]

  90. Ronald's Website - News Feeds said on

    [...] HTML 5: nav ambiguity resolved An e-mail from Chairman Hickson resolves an ambiguity in the nav element of HTML 5. One of the new things HTML 5 sets out to do is to provide web developers with a standardized set of semantic page layout structures. For example, it gives us a nav element to replace structures … [...]

  91. Stephen Agnic said on

    HTML5 has an unclear goal. It needs to fix its goal to become more simple and more involved with whatever it is they want to accomplish. Web applications is a relative term, all web sites have functionality – just because some have more function than others does not make one web site more of an application than another.

    It seems there is a lot of confusion. I currently think HTML is unable to attend to a lot of media needs. Why do we need plugins to watch videos and use Flash? They need to address more of the future of the Internet and the way media is distributed. There is also a widening language barrier that perhaps should be addressed as well.

    There is a lot going on and we’re talking about rounded borders and content sectioning. The future of HTML should be a globalization of the Internet, in both media distribution and in content.

  92. George Katsanos Blog » Blog Archive » Blogosphere debates heating up for HTML 5 said on

    [...] pretty nasty. A guy called John Allsopp commenting on Zeldman’s blog, explained why “HTML 5 is a mess“, and all hell broke loose. Then, couple of days ago, another guy, Bruce Lawson, an Opera [...]

  93. 24 Resources para HTML5 » CSS no Lanche said on

    [...] HTML 5: nav ambiguity resolved – Um post de Zeldman sobre o elemento nav do HTML 5. [...]

  94. Danny said on

    index.html

    [link href="my.site/dictionary.dic" rel="dictionary" type="text/css" media="aural" /]

    [div id="nav"]something[/div]

    [div id="lungs"]something[/div]

    dictionary.dic

    import http://w3.org/semantics/something as qqq (preferably browser should have this built-in)
    import http://who.int/html/something
    #nav {
    qqq:presentation:navigation
    }

    #lungs {
    biology:anatomy:*:lungs
    }

    This could be easily implemented inside some editor (drag&drop) and is fully extensible.
    Do You really think putting another elements or class names that simulates semantics is a future?

  95. HTML5 from a Mobile Perspective « Cloud Four said on

    [...] main complaint against HTML5 is the lack of extensibility. In particular, the ability for developers to define new semantic markup that provide meaning to a [...]

  96. HTML5 Resources & Discussion « Cloud Four said on

    [...] HTML 5: nav ambiguity resolved [...]

  97. SitePoint Podcast #20: YouTube Deep-sixes IE 6 said on

    [...] Comment by John Allsopp (Jeffrey Zeldman) [...]

  98. CaoInteractive Blog » Blog Archive » 23 Essential HTML 5 Resources said on

    [...] HTML 5: nav ambiguity resolved – A post by Zeldman on the HTML 5 Nav element [...]

  99. HTML5のセマンティックなタグはまだ議論沸騰中 - Blog on Publickey said on

    [...] of Web Standardsと呼ばれたこともあるJeffery Zeldman氏のブログのエントリ「HTML 5: nav ambiguity resolved – Jeffrey Zeldman Presents The Daily Report」では、前述のJohn Allsop氏、Bruce Lawson氏、そしてIan [...]

  100. Building Web Pages With HTML 5 - Webmonkey said on

    [...] how it could be used twice on the same page. For more on nav and a lively debate about HTML 5, see Jeffrey Zeldman's article on the nav element. The short story is that if you've been using a <div id="nav"> tag to hold your page [...]

  101. 24 Resources para HTML5 | Blog — Lúmen Web Solutions said on

    [...] HTML 5: nav ambiguity resolved – Um post de Zeldman sobre o elemento nav do HTML 5. [...]

  102. Reservations about HTML5 | Coffee on the Keyboard said on

    [...] with the ambiguity of certain new tags aside, these tags privilege, even codify, a certain paradigm in design. For lack of a better word, [...]

  103. HTML 5 23Դ_ said on

    [...] [...]

  104. 70 Must-Have CSS3 and HTML5 Tutorials and Resources | Web Resources | WebAppers said on

    [...] HTML 5: Nav Ambiguity Resolved – A clarification of the new nav element in HTML 5. [...]

  105. 70 Must-Have CSS3 and HTML5 Tutorials and Resources | trackteq.com said on

    [...] HTML 5: Nav Ambiguity Resolved – A construction of a brand brand brand brand brand brand brand brand brand brand brand brand brand brand brand new nav component in HTML 5. [...]

  106. 70 Must-Have CSS3 and HTML5 Tutorials and Resources - Iconlandia said on

    [...] HTML 5: Nav Ambiguity Resolved – A clarification of the new nav element in HTML 5. [...]

  107. Anonymous said on

    [...] 59. HTML 5: Nav Ambiguity Resolved [...]

  108. 70 Must-Have CSS3 and HTML5 Tutorials and Resources - Programming Blog said on

    [...] HTML 5: Nav Ambiguity Resolved – A clarification of the new nav element in HTML 5. [...]

  109. 70+ 必备的 CSS3 和 HTML5 教程资源 « 脚本 said on

    [...] HTML 5: Nav Ambiguity Resolved – 介绍 HTML5 中全新的导航元素。 [...]

  110. 70 Must-Have CSS3 and HTML5 Tutorials and Resources | ウェブ技術ネタのままとめ said on

    [...] HTML 5: Nav Ambiguity Resolved – A clarification of the new nav element in HTML 5. [...]

  111. Adept > 70 Must-Have CSS3 and HTML5 Tutorials and Resources said on

    [...] HTML 5: Nav Ambiguity Resolved – A clarification of the new nav element in HTML 5. [...]

  112. 23 Essential HTML 5 Resources « Vleerkatcreations said on

    [...] HTML 5: nav ambiguity resolved – A post by Zeldman on the HTML 5 Nav element [...]

  113. 70 CSS3 and HTML 5 tutorials and resources | Netfire.us - Design tutorials, articles, resources, and creative inspiration. said on

    [...] HTML 5: Nav Ambiguity Resolved [...]

  114. 70 Must-Have CSS3 and HTML5 Tutorials and Resources | huibit05.com said on

    [...] HTML 5: Nav Ambiguity Resolved – A clarification of the new nav element in HTML 5. [...]

  115. CSS3 Gallery, Showcase & Inspiration. Showcasing the best CSS3 Web Design on the Internet | 70 CSS3 & HTML5 Tutorials | CSS 3 Gallery said on

    [...] HTML 5: Nav Ambiguity Resolved – A clarification of the new nav element in HTML 5. [...]

  116. 25+ Great HTML 5 Resources to Get You Started | tripwire magazine said on

    [...] HTML 5: nav ambiguity resolved [...]

  117. Links for 2009-07-13 • Tiffany B. Brown said on

    [...] HTML 5: nav ambiguity resolved [...]

  118. Juli 2009 im Kontext | hyperkontext | Weblog said on

    [...] es wird auch heftig diskutiert: HTML 5: nav ambiguity resolved [Jeffrey [...]

  119. Ben said on

    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.

  120. CSS3 y HTML5: Tutoriales y recursos para el nuevo diseño web | Recursos para desarrollo y diseño web - AlmacenPlantillasWeb Blog said on

    [...] HTML 5: Nav Ambiguity Resolved – Información sobre el elemento “nav” en HTML 5. [...]

  121. The HTML5 Semantics Debate - ComponentGear.com Feed - ComponentGear.com said on

    [...] Jeffrey Zeldman approximates this “middle of the road” position, especially in the comments thread here. [...]

  122. Death To The Div » CSS/HTML, Coding, Rant » Russell Heimlich said on

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

  123. Bert said on

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

  124. HTML5ѧϰԴ-HTML/Xhtml-ҳ-ҳѧ said on

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

  125. SimpleBits ~ July 2009 Archives said on

    [...] —John Allsopp [...]

  126. Webkrauts » Das Endoskelett einer Webseite said on

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

  127. Fundamentally Navigable « IntelDesigner said on

    [...] Soon after this post was made Jeffery Zeldman made a post on HTML 5 that will enable a higher level of semantic code for [...]

  128. Brady J. Frey said on

    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.

  129. pwb said on

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

  130. engettals said on

    Sry for commenting off topic … which Word Press theme are you using? It’s looking awesome!

  131. html5 web resources start learn there « Just Press it! said on

    [...] HTML 5: nav ambiguity resolved – A post by Zeldman on the HTML 5 Nav element [...]

  132. Jean Ximenes - <Jean´s Blog /> said on

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

Comments off.