31 Aug 2009 2 pm eastern

Loving HTML5

Half of standards making is minutia; the other half is politics. Rightly or wrongly, I’ve long suspected that Atom was born, not of necessity, but because of conflicts between the XML crowd and the founders of RSS. Likewise, rightly or wrongly, I reckoned HTML5 was at least partly Hixie’s revenge against XHTML served as text/html.

And then a funny thing happened. Some friends and I gathered at Happy Cog’s New York studio to hash out the pros and cons of HTML5 from the perspective of semantic-markup-oriented web designers (as opposed to the equally valid perspectives of browser engineers and web application developers—the two perspectives that have primarily driven the creation of HTML 5).

Our first task was to come to a shared understanding of the spec. During the two days and nights we spent poring over new and changed semantic elements, we discovered that many things we had previously considered serious problems were fixable issues related to language.

Easy language problems

Some of these language problems are trivial indeed. For instance, on both the WHATWG and W3C sites, the specification is sometimes called “HTML 5″ (with a space) and sometimes called “HTML5″ (with no space). A standard should have a standard name. (Informed of this problem, Hixie has removed the space everywhere in the WHATWG version of the spec.)

Likewise, as an end-user, I found it confusing to be told that there is an “HTML5 serialization of HTML 5,” let alone an “XHTML 5 version of HTML5.” I requested that the two serializations be referred to as “HTML” and “XHTML”—emphasizing the distinction between the two kinds of syntax rather than drawing needless attention to version numbers. (Again, Hixie promptly updated the spec.)

Names and expectations

Some language problems are tougher—but still eminently fixable, because they are language problems that mar the presentation of good ideas, not bad ideas that require rethinking.

For example, in order to choose suitable names for the new semantic elements in HTML 5, Hixie analyzed classnames on thousands of websites to see what web designers and developers were already doing. If many designers and developers use classnames like “header” and “footer” to contain certain kinds of content, then HTML 5 should use these labels, too, Hixie and his colleagues reasoned. Doing so would make the purpose of the new elements intuitively obvious to working web professionals, removing the learning curve and encouraging proper element use from the get-go.

It’s a beautiful theory that comes straight out of Bert Bos’s W3C Design Principles. There’s just one problem. Header, and especially footer, behave differently from what their names will lead web designers and developers to expect. Developers will use it for the footer of the page—not for the footer of each section. And they will be frustrated that the footer in HTML5 forbids navigation links. After all, the footer at the bottom of web pages almost always includes navigation links.

To avoid misuse and frustration, the content model of footer should change to match that of header, so that it may be used concurrently as a template level element (the expected use) and a sub-division of section (the new use). Alternately, the element’s name should be changed (to almost anything but “footer”). Expanding the content model is clearly the better choice.

For the love of markup

HTML5 is unusual in many ways. Chiefly, it is the first HTML created in the time of web applications. It is also the first to be initiated outside the W3C (although it now develops there in parallel).

Not surprisingly in a specification that goes on for 900 pages, there are at least a dozen places in HTML5 where a thoughtful standardista might request clarification, suggest a change, or both. My friends and I have taken a stab at this ourselves, and will soon publish our short list of recommendations and requests for clarification.

Nevertheless, the more I study the direction HTML5 is taking, the better I like it. In the words of the HTML5 Super Friends, “Its introduction of a limited set of additional semantic elements, its instructions on how to handle failure, and its integration of application development tools hold the promise of richer and more consistent user experiences, faster prototyping, and increased human and machine semantics.”

Update

[4:47 PM EST] Calling all cars! The HTML5 Super Friends declaration of support is now live, as is the Super Friends Guide to HTML5 Hiccups (i.e. our technical recommendations).

ShortURL: zeldman.com/?p=2438

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

112 Responses to “Loving HTML5”

  1. Andrew Mager said on

    I la la la LOVE HTML 5!

  2. korbinian polk said on

    right! i also feel a little confused by the nomenclature of the footer element

  3. Kyle Weems said on

    There’s a meeting I would have loved to been a fly on the wall in. I agree that “authors” are going to need some time to really grok what’s all in there in full detail, and I’m looking forward to more studious people than me to share the details of the more obfuscated bits in a way that doesn’t make my head hurt.

  4. Adam said on

    Very much agree about the footer element. Hopefully we’ll see a change made there soon.

  5. CreativeNotice said on

    Right on about the Footer. LOL that was my first response as well. While I”m still not certain about the benefits of using Section of Div, I’m happy with the apparent attention to simplicity.

  6. CreativeNotice said on

    ^ should read Section over Div, as in in lieu of.

  7. Billee D. said on

    Just read about this meeting over on adactio. I’m glad some folks are taking the time to help clarify the HTML 5 spec.

    Thanks to you and everyone else for putting your heads together on this. I look forward to seeing what transpires. Super friends, unite!

  8. Kirk Franklin said on

    I’m not too crazy about aside vs. sidebar. Some structural elements in web publishing are analogous to print publishing, and "sidebar" makes more sense to me then "aside," which is more of a dramatic term.

  9. Michael Joyce said on

    Thank you for requesting clarification of the footer element. Every website I’ve been involved with has template-level navigation inside the footer, and the footer is always at the bottom of the page.

  10. Mike T. said on

    @CreativeNotice – is not intended to replace </code. A is for when you need structure with no semantics. A , on the other hand, does have semantic implications, especially when considering the outline of a document.

  11. Adam Detrick said on

    Elements like header and footer sometimes seem to imply more about the current state of web design than they do about semantics.
    I’m concerned that as the web evolves, the semantic meaning of elements like this may be lost, and we’ll kind of be where we started (using class names to emulate semantics within the markup).

    Just a few years ago, it may have been hard to imagine the usefulness of a dialog tag, but with the prevalence of web apps running in the browser now, it seems perfectly reasonable.
    If HTML5 were being developed in the 90′s, would we have a webring tag? It’s something I’ve wondered about HTML5, though I am happy in general with the direction it seems to be taking…

  12. Stephanie said on

    Even within an article I would want to include links in the “footer”, I hope this gets changed!

    Glad to see designers looking at the spec and providing feedback! Who did you provide it to? I’m wondering where to send my own… Thanks :)

  13. Erik said on

    “footer in HTML5 forbids navigation links” Wow. A container should never dictate it’s contents abilities, just it’s contents identity.

  14. Shane said on

    I agree with the “footer” argument, hopefully that gets fixed because I see a lot of strengths and things to get excited about with HTML5

  15. Ian Hickson said on

    Send feedback — it works. :-)

  16. Tristan Louis said on

    So… when will you change the DOCTYPE on your site from XHTML 1.1 ?

  17. Jenn said on

    If HTML5 were being developed in the 90’s, would we have a webring tag?

    Along that thought – mostly what I see is a spec that might as well be called HTMLBlog Instead of HTML5.

    I suppose I can see a use for header and footer elements, as much as I can see a use for thead and tfoot tags. How much of a use that is, depends on your site content.

    Still my major issue with this poll of most used elements that this spec seems to rely on – is how something like a “time” element, is going to be more used that a “search” element or a “comments” element.

    Also, I still can’t get over the spiffy-ness of the proposed NL element and the matching label from XHTML2 . An NL would be far more useful than a “nav” element with a heading element and a UL.

  18. Brad Bice said on

    @Andrew Mager: I think you meant “HTML5.” :)

    I agree that we should watch out about being TOO specific on these tag names. And I am personally confused as to the heirarchy between div, section and article, but I suppose the spec will clear that up if I read it (I hope.)

  19. Ryan Roberts said on

    @Kirk Franklin

    I’m not too crazy about aside vs. sidebar. Some structural elements in web publishing are analogous to print publishing, and “sidebar” makes more sense to me then “aside,” which is more of a dramatic term.

    Not sure I agree with that.

    Aside does not imply any presentation, it provides meaning to content that is related to the main article/content but can stand alone. This is very open but semantically useful.

    Sidebar on the other hand is heavily presentation and restrictive. While aside can easily be styled however you need, the sidebar is pretty much stuck to being a sidebar.

  20. Ryan Roberts said on

    @Jenn

    Also, I still can’t get over the spiffy-ness of the proposed NL element and the matching label from XHTML2 . An NL would be far more useful than a “nav” element with a heading element and a UL.

    You think dictating that navigation should be marked up as a list is better than allowing the engineer/designer to make that decision?

    I have to admit I preferred the nav list idea at first but navigation can often be more than just a list.

  21. Raph de Rooij said on

    The development of the HTML5 spec is both important and promising.

    However, one of the issues that needs to be solved is closing the gap that is developing between the HTML5 and Semantic Web communities. On Jeni Tennison’s blog you’ll find some outstanding articles on the subject.
    In my opinion, a solid support for semantic web technologies such as RDFa is necessary (for examples/inspiration, see Google Code for projects that use RDFa).

    Another issue is the inconsistency between WCAG 2.0 guideline 4.1 (more specifically checkpoint 4.1.1, a level A requirement) and HTML5 paragraph 9.1.2.4. Optional tags. This effectively means that you can never comply to the basic set of accessibility requirements when closing tags are omitted. At present, governments worldwide are in the process of incorporating WCAG 2.0 in their policies and/or legislation. From that perspective, omitting end tags will lead to complications for website owners that have to meet accessibility requirements and (have to) work with developers that don’t care to much about using end tags.

  22. Jeffrey Zeldman said on

    Calling all cars!

    The HTML5 Super Friends declaration of support is now live, as is the Super Friends Guide to HTML5 Hiccups (i.e. our technical recommendations).

  23. Twitter Trackbacks for Jeffrey Zeldman Presents [zeldman.com] on Topsy.com said on

    [...] Jeffrey Zeldman Presents http://www.zeldman.com/2009/08/31/loving-html5 – view page – cached Web design insights since 1995. Personal site of Jeffrey Zeldman, publisher of A List Apart Magazine, founder of Happy Cog Studios, co-founder of The Web Standards Project, co-founder of the Event Apart design conference, author of Designing With Web Standards. — From the page [...]

  24. Jeffrey Zeldman said on

    From that perspective, omitting end tags will lead to complications for website owners that have to meet accessibility requirements and (have to) work with developers that don’t care to much about using end tags.

    End tags are required in the XHTML serialization of HTML5 (i.e. the “XHTML syntax version”). But the W3C validation service (a port of validator.nu) doesn’t spank you for syntactical errors. You can mix XHTML and HTML syntax in HTML5 and be perfectly valid.

    What we’d like to see—and the Super Friends Guide to HTML5 Hiccups recommends this—is optional syntax checking in validator.nu, which would then get picked up by the W3C validation service. That way, developers who care about XHTML syntax can have what they want, and the rest of the universe can have what it wants. :)

  25. HTML5 feedback from prominent designers from Shelley Powers on 2009-08-31 (public-html@w3.org from August 2009) said on

    [...] with feedback from prominent designers. I noticed they hadn't been sent to the WG yet: Zeldman: http://www.zeldman.com/2009/08/31/loving-html5/ Jeremy Keith: http://adactio.com/journal/1604/ Joshua Allen: [...]

  26. John Faulds said on

    The HTML5 Super Friends declaration of support is now live

    Not sure about the cutesy unicorn; seems to detract from the message you’re trying to impart. :?

  27. Favrd. said on

    [...] of standards making is minutia; the other half is politics." LOVING HTML5: http://www.zeldman.com/?p=2438 zeldman (Jeffrey Zeldman) from NYC3 hours, 17 minutes agoView original [...]

  28. Jenn said on

    @Ryan Roberts

    I have to admit I preferred the nav list idea at first but navigation can often be more than just a list.

    I see your point and I’d be more down with the element if we could also get a equivalent element with it. There are times when I just don’t want to use a heading or strong for labeling my navigation. The currently isn’t giving me much more then using a did previously (minus adding vague semantic value), where the with the was giving me a significant improvement.

  29. Jenn said on

    eek for stripping out code tags!

    Mad libs time!

    I see your point and I’d be more down with the nav element if we could also get a label equivalent element with it. There are times when I just don’t want to use a heading or strong for labeling my navigation. The nav currently isn’t giving me much more then using a div did previously (minus adding vague semantic value), where the nl with the label was giving me a significant improvement.

  30. Ryan Roberts said on

    @Jenn I thought you were just making the comments more fun with a guessing game ;)

    But I see what you mean, there’s certainly room to refine the navigation markup in HTML5.

  31. Neal G said on

    I totally agree with you regarding Footer not being in the same scope as Header. I have no idea why anyone would make the two different in the first place. Perhaps it was just a mistake.

    “Likewise, rightly or wrongly, I reckoned HTML5 was at least partly Hixie’s revenge against XHTML served as text/html.”

    Also I’m really digging that sentence. I happen to agree with Hixie on that issue so I don’t blame him for sneaking that one in there.

    Still using HTML4 and will continue to until they get that all sorted out.

  32. Sasa Bogdanovic said on

    If there is still a chance, Jeffrey, you should use your authority and try to promote footer into feeter to stop further crippling of web pages, walking on one instead of two feet, which looks very normal to me. :)

  33. kl said on

    Great that you’re on board.

    Huge-type superfriends page wasn’t really needed. You could have just sent this to WHATWG or W3C mailinglist, like everyone else does.

  34. IRC logs: freenode / #whatwg / 20090901 said on
  35. dw said on

    Huge-type superfriends page wasn’t really needed. You could have just sent this to WHATWG or W3C mailinglist, like everyone else does.

    Oh, do I ever disagree. Having seen how the WHAT WG has handled large group submissions in the past, I think there would be open resistence and dismissive sniping in the back channel. Going public like this functions like th 95 Theses nailed to the door in Wittenburg — it publicly states the problems the Super Friends have with HTML5, which is ultimately more transparent than dumping it in the mailing lists. It gives the Average Joe designers and developers something to chew on. Much of the discussion has been in relative obscurity, open for all to see (mostly) but beyond the horizon of most of the rank and file. And that’s been fine, for the most part, but it’s time the people who actually will be working with HTML5 to start thinking about what it will mean for them. A public declaration invites them to start the discussion and start pinging Hixie and Co. with their issues with HTML5.

    Ultimately, this is good for HTML5, a vote of confidence from those who have helped build and flesh out the practice of web design over the last 15+ years. Debating the issues in the general web public will only make the spec stronger, and hopefully it will make Last Call far less painful.

    Let’s not just shunt this off to the mailing lists for Mark Pilgrim to write doggerel about. Do let’s talk about the issues in the interest of getting HTML5 right the first time — and a standard everyone can follow.

  36. Jeffrey Zeldman (08/09): Calling all cars! The... — BackType said on

    [...] Loving HTML5 on Jeffrey Zeldman Presents from 4 hours ago [...]

  37. Nick said on

    kl, could you quantify “wasn’t really needed”? It seems clear that the HTML5 Working Group haven’t had much luck communicating their message to the broader web development community. Smart marketing and clear language — and yes, fancy web pages with big type — are exactly what’s required at this stage of HTML5′s development.

  38. 일모리와 웹표준 said on

    [...] Loving HTML5 » Jeffrey Zeldman 8 hours ago [...]

  39. Shawn Hansen said on

    The name of the footer tag is an odd choice. Is it too late in the game to change this? Should it be changed? Will it? Or is this just one of the next generational “quirks” we’ll have to deal with?

  40. Arlen Walker said on

    Just curious: If you go to the validator (http://validator.nu), click “more options” and pop up the select box labeled “preset” you find the choices “XHTML5″ and “XHTML5 + ARIA” as possible ways to run the validator. I’m sure Henri would be interested in more specifics about how his software fails your concern about validation of XHTML 5 syntax. Has anyone forwarded them on to him?

  41. Ben said on

    @Jenn

    Along that thought – mostly what I see is a spec that might as well be called HTMLBlog Instead of HTML5.

    I like and thoroughly agree with this :)

    Your recommendations all make sense Jeffrey, after reading them I might even be slowly *gasp* coming around to HTML5. I mean HTMLBlog.

  42. Maciej Stachowiak said on

    What we’d like to see—and the Super Friends Guide to HTML5 Hiccups recommends this—is optional syntax checking in validator.nu, which would then get picked up by the W3C validation service. That way, developers who care about XHTML syntax can have what they want, and the rest of the universe can have what it wants. :)

    validator.nu does have an XHTML mode, and can even override the Content-Type. It doesn’t have support for checking as HTML and XML syntax at the same time however; you have to check twice if you want content that works as both.

  43. Ken said on

    And this discussion should show us all if html future is going into right direction. Using footer as page footer or section footer? Nav as just another empty (extra) tag or new navigation lists (nl) with more descriptive content? We all have different needs. That is the main reason why i don’t agree with HTML5 spec and I don’t like it – it’s not flexible. Few people, no matter how vast the knowledge they hold, can’t predict the demand for new features. For me, the future was XML (independent language) used to describe the structure of the document in a manner I see it. WCAG/W3C guys should focus on a new language that could describe document semantics not just another tags/elements.

  44. dzone.com - New links said on

    [...] 1 0 [...]

  45. James said on

    I am sure the use of the word ‘super’ was meant ironically, and not arrogantly.

    Exciting to see expert practitioners providing though-provoking feedback. But a grandiose & elitist collective might backfire ;-)

  46. Ms. Jen said on

    If one can’t put links in the footer, what does the spec expect you to put in it? Just a non-linked copyright?

    o.O

  47. Henri Sivonen said on

    @Superfriends:

    Thank you for the feedback! I’ll participate in discussion on the spec change proposals on the WG list, but there’s a feature request addressed specifically to me, so I’ll ask about it here.

    It would be great if Henri could add a toggle to the validator that will check for syntax. Something along the lines of “Also check for XHTML syntax validity.”

    Could you please elaborate on what specific validator behaviors you’d find useful? For example, would you like implied tags to be flagged or unquoted attribute values to be flagged?

    I think implementing your feature request as written would have annoying side effects, and I’m not sure if you really want the whole XHTML package including the annoying parts. For example, if the validator were to check that the input is both valid HTML5 and valid XHTML5, the validator would flag the the use of the nbsp entity as an error. If the validator were to additionally check that the input parses to the same tree as both HTML and XHTML, it would also flag a tr start tag following a table start tag without a tbody, thead or tfoot start tag in between as an error and it would flag a line feed immediately after a pre start tag as an error.

    @Raph de Rooij:

    Another issue is the inconsistency between WCAG 2.0 guideline 4.1 (more specifically checkpoint 4.1.1, a level A requirement) and HTML5 paragraph 9.1.2.4. Optional tags. This effectively means that you can never comply to the basic set of accessibility requirements when closing tags are omitted.

    I think WCAG 2 isn’t saying what you say it’s saying. The checkpoint reads (emphasis mine):

    In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.

    HTML5 allows certain tags to be omitted and thoroughly specifies how to process such markup. Therefore, omitting tags where permitted by HTML5 doesn’t fail the WCAG 2 checkpoint.

  48. Henri Sivonen said on

    Hmm. The styling doesn’t make em in a blockquote distinct. In my previous comment, the part “except where the specifications allow these features” is the part that I meant to emphasize.

  49. Hablando de HTML 5 : Hilo : Domestika said on

    [...] a pensar y leer qué dicen. Zeldman ha escrito un artículo que creo que explica bien su postura: Loving HTML 5Y bien, yo por mi parte voy a ir leyendo de manera "un poco menos escéptica" sobre HTML [...]

  50. links for 2009-09-01 « burningCat said on

    [...] Loving HTML5 (tags: html5 Markup html standards reference webdesign) [...]

  51. Ben said on

    Love the unicorn! :)

  52. Don Ulrich said on

    Shame on all of you. HTML5 is nothing more than fashion. Markup should be ubiquitous and transparent. It is funny you should mention Atom Z, this could be an ironic comparison in the future. HTML5 is so shallow and of the moment.

  53. Sam Ruby said on

    Henri: I do believe that optionally flagging, as a warning, a new line immediately after <pre> would be helpful in debugging content produced by an XML toolchain that may not be interpreted as intended. And I’m willing to help.

  54. Noscope said on

    After having been convinced of the simpler boons of HTML5 by James, last night I finally understood the more long-term boons by readingthis piece by Jeffrey Zeldman. Shortly after, I converted this blog from XHTML to HTML5….

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

    [...] Loving HTML5 [...]

  56. HTML 4 5 6...: HTML5 nepotřebuje Supermana, má totiž Superkamarády said on

    [...] za ní stojí Jeffrey Zeldman, který ještě nedávno HTML5 silně kritizoval.Dnes v příspěvku Loving HTML5 říká:Čím víc zkoumám HTML5, tím víc se mi líbí.Stránka HTML5 Super Friends výslovně [...]

  57. Rhyaniwyn said on

    Aside does not imply any presentation, it provides meaning to content that is related to the main article/content but can stand alone. This is very open but semantically useful.

    aside is a deliberate analogy to the way print publications present content in articles — with pullquotes and biographies embedded within the article text — related, but separate. Looked at from a certain perspective it can be used to confer meaning to blocks of text, but IMHO it is drawn from something that has more to do with visual presentation than semantics, which is part of the problem with it.

    Certainly I can see its usefulness in certain semantic scenarios, but given the prevalence of sidebars on the web, it is also guaranteed to cause confusion and be misused. After all, “My sidebar contains content that is not within the flow of the page/article, but is tangentially related to it.” Sometimes aside will be suitable for a sidebar, yes, but not always. However, I foresee it becoming a defacto sidebar tag.

    I think that we borrow far too heavily from print due to our understandable desire to have the advanced layout capabilies the a print medium. The problem is that the print analogy simply isn’t appropriate. To state the obvious, the web is a completely different animal. When you are using styles in a word processing program you don’t worry about the semantics of the heading, you use the heading style so that the text visually appears to be a heading. Print is an entirely visual medium and that makes it a poor model to inspire web markup.

    And personally the more I think about it, the more I find section ridiculous. div is short for division. In the english language division and section are synonymns. I don’t know about you, but I’ve used class=”section” in divisions to distinguish between divisions I was using as discrete page sections versus divisions I added as CSS hooks (much as we try to avoid it, it’s sometimes necessary). Does this mean section is more meaningful than division, or does it just mean that division has lost its meaning due to its useage? I assert the latter.

    The spec’s treatment of section versus division makes division a tag that exists purely for presentation purposes and meaningless semantically. This reflects the current useage, but the current useage exists because of necessity. Does adding section really help or will section become subject, over time, to the same abuse div suffered from? I suggest it’s likely (although avoidable).

    And aren’t we as standardistas against the idea of marking up our content for presentation rather than semantics? Obviously there is a point where pragmatism must come into play. But the treatment of div in the spec contradicts its theology regarding the treatment of other presentational elements such as small.

    In point of fact I support aside, if it is clearly and usefully defined. Useage examples have been the most helpful for me in reading the specification. I also support article as I like the notion of using it to mark up excerpts from other pages (ie: the summary/excerpt of a blog entry, which is an independent article, that is shown on the category or front page of a blog — but, on that note, the spec suggests article for comments as I recall; I would probably lean toward aside). I even support section for the reason that the new tags, unlike most of the old tags are using full words as tag names rather than shortened forms of words. section lends symmetry to the tags and its introduction alongside aside, header, and footer (if redefined as the Super Friends suggest) will gradually phase out the need for the presentational divs that have become so meaningless. Introducing section as distinct from div is a psychological necessity more than anything else.

    But I am blathering…

  58. Wine Rack Review: 2003 Alma Negra - The Spider King said on

    [...] "Half of standards making is minutia; the other half is politics." LOVING HTML5: http://www.zeldman.com/?p=2438 21 hrs [...]

  59. Jeff King said on

    @Rhyaniwyn

    <section> is used to provide logical grouping of content — often under a common heading. Even in the absence of a heading, the content of a <section> tag should be logically connected.

    <div> does not have much semantic meaning, and is typically used as a catch-all when a block level element is required and none with appropriate semantic meaning is available.

  60. Jeff King said on

    Guide to HTML5 Hiccups:

    We would like to encourage spec authors to be conservative in including new tags, and only do so when they addition of the tag allows for significant gains in functionality. For example, article and section are identical except that article allows a pubdate attribute. We would suggest that article be dropped and section be adapted to allow an optional pubdate attribute or, even better, more explicit metadata.

    While code and section may be nearly identical from a technical perspective, they have distinct semantic meaning.

    article is stand-alone content, independent from that of the website. section is a logical subpart of the greater content. So, every article element may be a semantically replaced by a section element, but not every section element could be semantically replaced by an article element.

    So, the question becomes: is there enough “article” content to justify an article element? Given the saturation of blogs and news sites on the internet, the answer is unquestionably: yes.

    Not only is there semantic clarity by keeping both elements, there is practical advantage.

    As h1-6 is allowed to be replaced by nested h1s in HTML5, having an article element is very helpful to establish a baseline for the consistent styling of subsequently nested section and h1 elements.

  61. Tantek said on

    Henri, regarding the validator enhancement request:

    While more specific toggles (e.g. “Check for quoted attributes”) may benefit some power users, the largest benefit would be realized by providing at least a high-level “XHTML syntax” toggle, which could (perhaps with progressive disclosure help text) document what it is checking in addition, like:

    * quoted attributes
    * self-closed empty elements (e.g. <meta />, <link />, <img />, <br /> etc.)
    * explicit closing tags (for non-empty elements)
    * named entities defined by XHTML 1.0
    * … etc.

    We want the ability to check for stricter syntax “at validation time” to be conducive to more efficient authoring/development. Every good programmer knows bugs are much more quickly caught and fixed at compile-time than at run-time. Validation is the compile-time of HTML.

    All of the above syntax checking (and more) is currently provided by the W3C Validator when validating XHTML 1.0 DOCTYPE documents served as text/html. We want the option for the same (or better?) level of XHTML syntax checking when validating HTML5 documents as text/html.

  62. Jeffrey Zeldman said on

    [T]he largest benefit would be realized by providing at least a high-level “XHTML syntax” toggle, which could (perhaps with progressive disclosure help text) document what it is checking in addition[.]

    Precisely what I would have said if I could have said it.

    Thanks, Tantek!

  63. A List Apart: Articles said on

    [...] the publication of Loving HTML and the HTML5 Super Friends documents yesterday, Hixie fixed the inconsistency in the WHATWG [...]

  64. sunny said on

    On a less technical note, I started to read the spec, but had to stop. The poor grammar and wordiness of the document started to make me twitch (I’m 50% developer, %50 copy editor).

    Wading through a document of that size is enough of a chore. When it’s so poorly written that I’m simultaneously editing the language while reading, it’s time to abandon it.

    The first item on my wish list for HTML5 is that the spec be written (or at least edited) by people who know how to write.

  65. aarontgrogg said on

    wonder twin powers. activate!!

  66. Technology / Upcoming said on

    [...] Loving HTML5 zeldman.com — Half of standards making is minutia; the other half is politics. Rightly or wrongly, I’ve long suspected that Atom was born, not of necessity, but because of conflicts between the XML crowd and the founders of RSS. Likewise, rightly or wrongly, I reckoned HTML5 was at least partly Hixie’s revenge against XHTML served as text/html. More… 0 Comments Share [...]

  67. Henri Sivonen said on

    @Tantek:

    (Quotes reordered.)

    While more specific toggles (e.g. “Check for quoted attributes”) may benefit some power users, the largest benefit would be realized by providing at least a high-level “XHTML syntax” toggle,

    We want the ability to check for stricter syntax “at validation time” to be conducive to more efficient authoring/development. Every good programmer knows bugs are much more quickly caught and fixed at compile-time than at run-time. Validation is the compile-time of HTML.

    I take it the use case is having more strictness to avoid accidentally triggering looseness and the use case is not serving the same document as both text/html and application/xhtml+xml. Did I understand the use case correctly?

    * quoted attributes

    Assuming the intent isn’t to serve the document as application/xhtml+xml, is it necessary to require quotes when a boolean attribute is used without the equals sign at all (e.g. <input type=”radio” checked />)? It seems to me that writing <input type="radio" checked="" /> does not help catch run-time bugs if run-time is text/html.

    * self-closed empty elements (e.g. , , , etc.)

    But this does not catch any run-time bug at compile time if you are going to serve the document as text/html. Why is this needed?

    It seems to me that teaching authors that /> “closes” HTML elements in text/html poisons their mental model of how closing actually happens. If they try to apply the /> model to div or script in text/html, failure ensues.

    * explicit closing tags (for non-empty elements)

    I agree. This is already planned but blocking on more urgent Firefox work in the parser code base. (Maybe I should just squeeze this one in sooner, since soon I’ve spent more time talking about this one than what it would take to implement it.)

    * named entities defined by XHTML 1.0

    The thing is, you wouldn’t get this with an “also check XHTML validity” option. If you use the <DOCTYPE html> doctype, as you would for HTML5 in text/html, the only entities available on the XHTML side are the XML predefined entities, and we can’t change that without overstepping the jurisdiction of the HTML5 spec and changing XML.

    * … etc.

    I suspect you wouldn’t find the “etc” part desirable. Sam Ruby suggested that I implement the “etc” part but not to promote XHTML-style markup but to demonstrate to people it’s not worth it.

    All of the above syntax checking (and more) is currently provided by the W3C Validator when validating XHTML 1.0 DOCTYPE documents served as text/html. We want the option for the same (or better?) level of XHTML syntax checking when validating HTML5 documents as text/html.

    No offense intended, but frankly, this looks more like “we don’t want change” than “these validator behaviors are useful to authors for these reasons”.

    @Sam:

    I do believe that optionally flagging, as a warning, a new line immediately after would be helpful in debugging content produced by an XML toolchain that may not be interpreted as intended.

    The problem is that the option addresses a pretty esoteric use case. It probably shouldn’t be esoteric, but how many people are equipped to interpret the results of such debug messages correctly and know to ask for such debug messages? When there’s a line break there, the validator doesn’t know if it is a line break that is naïvely emitted by an XML serializer and gets eaten against the intent of the serializer writer or whether the line break is emitted by a text/html serializer specifically so that it gets eaten in the parser so that the next line break is preserved in case there is one. For example, the Validator.nu HTML serializer outputs a line feed after a pre, listing or textarea start tag unconditionally so that emitting the break does not need to be deferred until the serializer sees if there’s a text node starting with a line feed next.

  68. zcorpan said on

    (Informed of this problem, Hixie has removed the space everywhere in the WHATWG version of the spec.)

    It was removed in the W3C version, too. If you don’t see it, you’re not reading the latest version.

  69. Sam Ruby: Polyglot Validation said on

    [...] while this request sounds deceptively simple, the fact of the matter is that there are a lot of unanswered questions.  At the present time I have neither the time nor the inclination to work out all of the [...]

  70. Sam Ruby said on

    I’m make a call for test cases, coupled with a concrete offer to help.

  71. Eric's Archived Thoughts: Nine Into Five said on

    [...] the other end of the two days, I felt a good deal more calm and hopeful than I did going in. As Jeffrey said, “the more I study the direction HTML5 is taking, the better I like it”. While there [...]

  72. rick resnick said on

    as far as i’m concerned, until all browsers support HTML5 reasonably equally, i won’t be using it. i’m not enamored by different browser hacks and “clever” coding dating back to all the netscape 4 crap, IE5 & 6 crap.
    all this hype is taking yourselves way too seriously. i wish people would put more effort into decent content.

  73. Tantek said on

    @Henri, thanks for the good follow-up questions. A few answers:

    Re: boolean attributes. e.g. checked=”checked”
    * error: <input type="radio" checked />
    * error: <input type="radio" checked="" />
    * error: <input type="radio" checked="false" /> — does not mean what it says
    * error: <input type="radio" checked="off" /> — does not mean what it says
    * warning: <input type="radio" checked="true" /> — will work, but misleads
    * warning: <input type="radio" checked="on" /> — will work, but misleads
    * right: <input type="radio" checked="checked" />

    Re: Why is this (checking self-closed empty elements) needed?
    * error: <br></br> — per http://www.w3.org/TR/xhtml1/guidelines.html#C_2 “gives uncertain results in many existing user agents.” = runtime error.
    * right: <br />

    Re: named entities. You’re right, the XHTML (1.0) vs. XML distinction may be another source of runtime errors. Thus:
    * warning: &nbsp; – works in HTML(n) and XHTML 1.0, fails in XML.
    * right:  
    * right: &amp; , &quot; , &apos; , &lt; , &gt;

    That’s a good start. Thanks again for the good questions and comments. Watch the following for updates:

    Super Friends Guide to HTML5 Hiccups: Validation of XHTML and HTML

  74. Tantek said on

    that second to last “* right:” should read:
    * right:  

  75. Tantek said on

    So I *did* type it right the first time. Ah WordPress, you’re trying too hard to fix things that don’t need fixing. Let’s try once again, with spaces to hopefully disrupt WordPress’s overeager “correction” code:

    * right: & # 1 6 0 ;

  76. Will said on

    “Developers will use it for the footer of the page—not for the footer of each section. And they will be frustrated that the footer in HTML5 forbids navigation links. After all, the footer at the bottom of web pages almost always includes navigation links.”

    This is absolutely incredulous. I can’t believe this is how header and footer are proposed now, especially if they wanted it intuitive or how people are working now.
    How out of touch can you be? I am hoping this was somehow just an oversight.

  77. Get ready for HTML 5 on Flickr - Photo Sharing! said on

    [...] header and footers are also possible. Thus, the nesting dolls inside nesting dolls inside the box. http://www.zeldman.com/2009/08/31/loving-html5/ explains it all very well. Posted 3 hours ago. ( permalink [...]

  78. Henri Sivonen said on

    @Tantek:

    thanks for the good follow-up questions

    Thank you for your answers.

    I notice you didn’t address my question about the use case. It’s hard to meaningfully evaluate your other answers without knowing what use case is being addressed.

    * error: <input type=”radio” checked />

    Why is this error useful for text/html authors?

    * error: <input type=”radio” checked=”" />

    This is currently permitted in both HTML5 and XHTML5. Why would it be useful to make this an error?

    * error: <input type=”radio” checked=”false” /> — does not mean what it says
    * error: <input type=”radio” checked=”off” /> — does not mean what it says
    * warning: <input type=”radio” checked=”true” /> — will work, but misleads
    * warning: <input type=”radio” checked=”on” /> — will work, but misleads

    These are all currently errors. I don’t see why it would be useful to downgrade “true” and “on” to non-errors. Doing so would imply that “false” and “off” are OK, too, which would be a totally wrong impression to give to authors.

    * right: <input type=”radio” checked=”checked” />

    This is already permitted in both HTML5 and XHTML5.

    * error: <br></br> —

    The </br> part is already an error in HTML5. The question I’m interested in is whether you are asking for the <br> part to become an error as well and, if so, why would it be useful to text/html authors to make it an error.

    per http://www.w3.org/TR/xhtml1/guidelines.html#C_2 “gives uncertain results in many existing user agents.” = runtime error.

    I think it would be productive to frame the discussion in terms of usefulness to authors currently and in the future. I think framing the discussion in terms of past non-normative material in publications to be superceded by HTML5 is not as productive.

    * right: <br />

    This is already permitted in both HTML5 and XHTML5.

    What about <br/>? (It is also already permitted in both HTML5 and XHTML5.)

    * warning:   – works in HTML(n) and XHTML 1.0, fails in XML.

    The concept of something working in XHTML but failing in XML is a bit odd in terms of what XHTML is supposed to be. :-)

    Why would this warning be useful for text/html authors?

  79. はてなブックマーク - vantguarde - HTML said on

    [...] Loving HTML5 http://www.zeldman.com [...]

  80. Adactio: Journal—Testing HTML5 said on

    [...] email. Well, we will. But I think there’s a lot of value in publicly discussing this stuff (and soliciting feedback). Mostly though, I’ll feel a lot more comfortable about raising an issue if I can back it up with [...]

  81. Lars Gunther said on

    As Sam Ruby points out, there might be multiple reasons why somebody would like to use polyglot documents. My reason is primarily didactic. (I teach web development for a living and I am involved with The Education task Force at WaSP and lately also OWEA.)

    My experience is that enforcing quotation marks on attribute values and the use of closing tags helps to reduce student errors.

    There might be technical minutiae that is required for a 100 % true polyglot conformance checker. It might even be that there is some details that simply make such a 100 % score impossible. But that is beside my point.

    Arguing about them is perhaps the reaction of a highly trained technical mind and having an unquestionable expertise in the subject matter. But I would argue that most people involved in the WHAT WG effort do not have the same level of expertise that I and my colleagues have in teaching this stuff.

    It seems to me that teaching authors that /> “closes” HTML elements in text/html poisons their mental model of how closing actually happens. If they try to apply the /> model to div or script in text/html, failure ensues.

    This is simply not the issue you make it to be.

    If a student would try a trailing slash on a div or a script tag, it will only occur once. They’ll learn quickly that it does not work through trial and error.

    By coincidence I actually touched upon this in my class today! I rarely get to teach genius caliber students, but when I told my students that the trailing slash served to close the element in XHTML, but for us it is simply a reminder that the element is void, they all understood.

    I also showed them an example of a paragraph that seemingly contained a table, from a markup point of view. I told them, that if they’d validate the code it would complain about the closing p-tag, and say that it did not match a start tag. Using XHTML-ish rules in my classroom suddenly made the validator an even greater teaching tool. Had the students relied upon the implicit closing of tags and omitted the ending p, they would be more prone to believe that a paragraphs actually can contain tables.

    Now, I have argued from experience, not from “hard data” or scientific study. But before this is dismissed I would like to see any hard data or scientific studies about student learning habits that suggest I’m wrong. Until such data is presented I think it might be wise to listen to those who at least have considerable experience in this field.

  82. Jeffrey Zeldman said on

    What Lars said.

  83. Jeffrey Zeldman said on

    (Clears throat)

    Is this thing on?

    HTML5 is extending footer to be more like header.

    Hat tip: @rakesh314.

  84. Jeff King said on

    I understand that a details element would need a legend child (or renamed equivalent).

    But couldn’t legend be dropped completely for the figure element? Wouldn’t a simple paragraph suffice?

  85. Jeff King said on

    Also, perhaps a h1 is more appropriate than legend (or any new replacement) for the details element.

  86. Jeffrey Zeldman Is Loving HTML5 | MediaPowerLab said on

    [...] Article by Jeffrey Zeldman. [...]

  87. Ionut Popa said on

    I started a linkedIn group about HTML5/CSS3 for those interested at http://www.linkedin.com/groups?gid=2071438

  88. Tantek said on

    Henri,

    You’ve demonstrated in your follow-ups why it’s not productive to make me document the details of what it means to validate for both XHTML syntax and HTML syntax simultaneously. (so no, I wouldn’t want to turn any of those existing “errors” into “warnings”). And you’re right about it being odd to allow XHTML 1.0 named entities, I retract that “warning” (any named entities beyond the 5 in XML should be errors when validating for XHTML syntax).

    The simple implementation answer is:

    just provide the checkbox to validate both HTML and XHTML syntaxes, and do three things, the first two of which you’ve already implemented (as separate features) :

    1. validate the document for HTML syntax (e.g. what your validator does when given HTTP content-type “text/html”)

    2. validate the document for XHTML syntax (e.g. what your validator does when given HTTP content-type “application/xhtml+xml” )

    3. check for any possible element tree differences (e.g. absence of ) and error if any differences are present.

    Perhaps also check for white-space differences (e.g. the newline following a difference). In practice I’ve never run into that being a source of problems (unlike the others), and thus it’s up to you if you want to implement that check as well just for the sake of thoroughness.

    Regarding use cases:

    1. Fewer runtime errors (not sure how else you want this restated.) More efficient authoring, design, and development is *the* primary use case for checking for both HTML and XHTML syntax and what the Superfriends guide has been pointing out since day 1. This is also what Lars said above. As someone who has also taught many people how to author HTML (and XHTML), I’ve consistently found that teaching people to author valid XHTML results in fewer odd bugs in their CSS or DOM manipulation javascripts when they check their pages in the browser.

    This increased productivity is sufficient reason for why this is “useful for text/html authors”. But as if that’s not enough:

    2. Enable processing by XML tools. While this is a general class of use cases, it’s very concrete for modern web designers who for example publish their contact info using hCard, which then they offer “Add to Address Book” functionality using a service that converts their hCard to vCard using the XSLT X2V. Ideally the page is well-formed XML and thus it just works. If not, such services first have “Tidy” the page, which both takes longer, and may result in unexpected changes to the tree (not quite as predictable/reliable as “just” using XML). The same is true for publishing hCalendar and offering “Add to Calendar” functionality through X2V. And no, asking folks to just wait for/use an HTML5-aware version of “Tidy” which will be here/available any time now is neither a practical here-and-now answer, nor does it address the general class of use cases, nor does it mitigate the efficiency problem (having to “Tidy” before being able to process as XML).

  89. Lars Gunther said on

    I have expanded upon my thoughts at http://itpastorn.blogspot.com/2009/09/pedagogic-validation-of-html.html (linking back to this site, so this could perhaps be considered a trackback…)

    I have also entered into a dialog with Sam Ruby and provided him with a few test cases for a pedagogic validation option: http://intertwingly.net/blog/2009/09/08/First-Polyglot-Validator-Check-Deployed

  90. Itpastorn's Thinkpad update & maintenance blog: Pedagogic validation of HTML said on

    [...] commented on Zeldmans blog that from my perspective these are non issues. Let me tell you about the everyday problems I [...]

  91. house of user - Projektmanagement | Usability Engineering | E-Learning | Redaktion said on

    [...] hält sich in Grenzen. Die Gurus klatschen Beifall, allen voran Jeffrey Zeldman mit Loving HTML5, Wendy Chisholm unter dem Gesichtspunkt der Barrierefreiheit und, im Zusammenhang mit Googles [...]

  92. The WHATWG Blog » Blog Archive » Spelling HTML5 said on

    [...] and sometimes “HTML 5” (even on whatwg.org). This kind of inconsistency is bad for branding. The Super Friends pointed this issue out as the first thing they pointed [...]

  93. NY Web Standards Meetup—HTML5 part one | theMechanism said on

    [...] Loving HTML5. Jeffrey Zeldman. [...]

  94. npme's Network on Delicious said on

    [...] Loving HTML5 – Jeffrey Zeldman Presents The Daily Report SAVE [...]

  95. Hacker News | HTML 5 is a mess said on
  96. Planet HTML5 said on

    [...] and sometimes “HTML 5” (even on whatwg.org). This kind of inconsistency is bad for branding. The Super Friends pointed this issue out as the first thing they pointed [...]

  97. HTML5 – jetzt neu mit gebremstem Schaum said on

    [...] Jeffrey Zeldman: »Loving HTML5« [...]

  98. Welcome To: Loving HTML 5 said on

    [...] HTML 5 Half of standards making is minutia; the other half is politics. Posted by Rick at 10:07 [...]

  99. A collection of HTML5 links, documents and discussions - paulcarvill.com said on
  100. Redesign using HTML5 & CSS3 said on

    [...] I have been meaning to completely redesign my personal website for some time now. There has been a flurry of support for the HTML5 spec recently, and even while browsers do not officially support the new structural [...]

  101. Templete @Son Of Moto user said on

    good information would like to try it : Son Of Moto Templete user

  102. web_design said on

    [...] days ago by emilbjorklund6 commentssharecancelloading…84555657Loving HTML5 (zeldman.com)submitted 23 days ago by AnotherWebDesigner13 [...]

  103. weekly links, 31st Aug – 6th Sep « Marc Watts web development said on

    [...] Loving HTML5 [...]

  104. Talk:HTML 5 - Wikipedia, the free encyclopedia said on

    [...] a space, but a newer Editor's Draft no longer has the space. Removing the space was requested by The HTML5 Super Friends. Hsivonen (talk) 13:06, 28 September 2009 [...]

  105. HTML5 Round-up | Broken Links said on

    [...] this month a group of high-profile developers — including Dan Cederholm and Jeffrey Zeldman—got together to discuss the spec and declare their support (albeit with some caveats) for the [...]

  106. Nine Into Five - Programming Blog said on

    [...] the other end of the two days, I felt a good deal more calm and hopeful than I did going in. As Jeffrey said, “the more I study the direction HTML5 is taking, the better I like it”. While there [...]

  107. HTML5 Redefines Footer - Programming Blog said on

    [...] seems like only yesterday that the HTML5 Super Friends asked the HTML5 working groups to rethink footer’s content model to avoid web developer misuse and frustration. Okay, it wasn’t yesterday, it was Monday. [...]

  108. Loving HTML5 - Programming Blog said on

    [...] ShortURL: zeldman.com/?p=2438 [...]

  109. Lenguajes X » HTML 5 Superfriends said on

    [...] nos podíamos temer tras leer Loving HTML5. Al rato Zeldman lo contaba en el propio post: [4:47 PM EST] Calling all cars! The HTML5 Super [...]

Comments off.