16 Jul 2009 9 am eastern

HTML 5 is a mess. Now what?

A few days ago on this site, John Allsopp argued passionately that HTML 5 is a mess. In response to HTML 5 activity leader Ian Hickson’s comment here that, “We don’t need to predict the future. When the future comes, we can just fix HTML again,” Allsopp said “This is the only shot for a generation” to get the next version of markup right. Now Bruce Lawson explains just why HTML 5 is “several different kind of messes:”

  1. It’s a mess, Lawson says, because the process is a mess. The process is a mess, he claims, because “[s]pecifying HTML 5 is probably the most open process the W3C has ever had,” and when you throw open the windows and doors to let in the fresh air of community opinion, you also invite sub-groups with different agendas to create competing variant specs. Lawson lists and links to the various groups and their concerns.
  2. It’s a “spec mess,” Lawson continues, citing complaints by Allsopp and Matt Wilcox that many elements suffer from imprecise or ambiguous specification or from seemingly needless restrictions. (Methinks ambiguities can be resolved, and needless restrictions lifted, if the Working Group is open to honest, accurate community feedback. Lawson tells how to contact the Working Group to express your concerns.)
  3. Most importantly, Lawson explains, HTML 5 is a backward compatibility mess because it builds on HTML 4:

[I]f you were building a mark-up language from scratch you would include elements like footer, header and nav (actually, HTML 2 had a menu element for navigation that was deprecated in 4.01).

You probably wouldn’t have loads of computer science oriented elements like kbd,var, samp in preference to the structural elements that people “fake” with classes. Things like tabindex wouldn’t be there, as we all know that if you use properly structured code you don’t need to change the tab order, and accesskey wouldn’t make it because it’s undiscoverable to a user and may conflict with assistive technology. Accessibility would have been part of the design rather than bolted on.

But we know that now; we didn’t know that then. And HTML 5 aims to be compatible with legacy browsers and legacy pages. …

There was a cartoon in the ancient satirical magazine Punch showing a city slicker asking an old rural gentleman for directions to his destination. The rustic says “To get there, I wouldn’t start from here”. That’s where we are with HTML. If we were designing a spec from scratch, it would look much like XHTML 2, which I described elsewhere as “a beautiful specification of philosophical purity that had absolutely no resemblance to the real world”, and which was aborted by the W3C last week.

Damned if you do

The third point is Lawson’s key insight, for it illuminates the dilemma faced by HTML 5 or any other honest effort to move markup forward. Neither semantic purity nor fault-tolerance will do, and neither approach can hope to satisfy all of today’s developers.

A markup based on what we now know, and can now do thanks to CSS’s power to disconnect source order from viewing experience, will be semantic and accessible, but it will not be backward compatible. That was precisely the problem with XHTML 2, and it’s why most people who build websites for a living, if they knew enough to pay attention to XHTML 2, soon changed the channel.

XHTML 2 was conceived as an effort to start over and get it right. And this doomed it, because right-wing Nativists will speak Esperanto before developers adopt a markup language that breaks all existing websites. It didn’t take a Mark Pilgrim to see that XHTML 2 was a dead-end that would eventually terminate XHTML activity (although Mr Pilgrim was the first developer I know to raise this point, and he certainly looks prescient in hindsight).

It was in reaction to XHTML 2′s otherworldliness that the HTML 5 activity began, and if XHTML suffered from detachment from reality, HTML 5 is too real. It accepts sloppiness many of us have learned to do without (thereby indirectly and inadvertently encouraging those who don’t develop with standards and accessibility in mind not to learn about these things). It is a hodgepodge of semantics and tag soup, of good and bad markup practices. It embraces ideas that logically cancel each other out. It does this in the name of realism, and it is as admirable and logical for so doing as XHTML 2 was admirable and logical in its purity.

Neither ethereal purity nor benign tolerance seems right, so what’s a spec developer to do? They’re damned either way—which almost suggests that the web will be built with XHTML 1.0 and HTML 4.01 forever. Most importantly for our purposes, what are we to do?

Forward, compatibly

As the conversation about HTML 5 and XHTML has played out this week, I’ve felt like Regan in The Exorcist, my head snapping around in 360 degree arcs as one great comment cancels out another.

In a private Basecamp discussion a friend said,

Maybe I’m just confused by all the competing viewpoints, but the twisted knots of claim and counterclaim are getting borderline Lovecraftian in shape.

Another said,

[I] didn’t realize that WHATWG and the W3C’s HTML WG were in fact two separate bodies, working in parallel on what effectively amounts to two different specs [1, 2—the entire thread is actually worth reading]. So as far as I can tell, if Ian Hickson removes something from the WHATWG spec, the HTML WG can apparently reinsert it, and vice versa. [T]his… seems impossibly broken. (I originally used a different word here, but, well, propriety and all that.)

Such conversations are taking place in rooms and chatrooms everywhere. The man in charge of HTML 5 appears confident in its rightness. His adherents proclaim a new era of loaves and fishes before the oven has even finished preheating. His articulate critics convey a palpable feeling of crisis. All our hopes now hang on one little Hobbit. What do we do?

As confused as I have continually felt while surfing this whirlwind, I have never stopped being certain of two things:

  1. XHTML 1.0—and for that matter, HTML 4.01—will continue to work long after I and my websites are gone. For the web’s present and for any future you or I are likely to see, there is no reason to stop using these languages to craft lean, semantic markup. The combination of CSS, JavaScript, and XHTML 1.0/HTML 4.01 is here to stay, and while the web 10 years from now may offer features not supported by this combination of technologies, we need not fear that these technologies or sites built on them will go away in the decades to come.
  2. That said, the creation of a new markup language concerns us all, and an informed community will only help the framers of HTML 5 navigate the sharp rocks of tricky shoals. Whether we influence HTML 5 greatly or not at all, it behooves us to learn as much as we can, and to practice using it on real websites.

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

[tags]HTML5, HTML4, HTML, W3C, WHATWG, markup, webstandards[/tags]

Filed under: Accessibility, Design, HTML, HTML5, industry, spec, Standards, State of the Web, W3C, Web Design, XHTML

88 Responses to “HTML 5 is a mess. Now what?”

  1. Jeff Siarto said on

    It amazes me that we have 2 separate groups working in parallel on the same spec? Is there something I’m missing here?

  2. Alexis Deveria said on

    Great post, also by Bruce. I think your conclusion is especially important, Jeff. Indeed, whatever comes of HTML 5, staying informed about developments and experimenting here and there with what browsers support is probably the best thing for developers to do right now.

  3. Eric L. Epps said on

    I, for one, don’t foresee abandoning XHTML 1.0 for developing websites–even if I end up serving them as HTML 5 (and, as browser support continues to improve, adding header, footer, etc. tags).

    That said, since HTML 5 supports XHTML syntax, it makes sense to have some sort of ability to switch between HTML and XHTML syntax, similar to Strict and Transitional. Those who prefer the tighter XHTML can use that, and those who prefer looser HTML can use that–just like we have with HTML 4.01 and XHTML 1 now.

  4. rkd (Ryan Davidson) said on

    Very relieved to read your last two points about XHTML/the current way of doing things (or is it now the old way? I’m still not sure…). At the end of the day I’m just one of countless “foot-soldier” web developers whose primary concern is producing beautiful, usable websites following the standards and best-practices set forth by people like you, Zeldman.

    Sounds like the thick dust cloud kicked up by HTML5 is still settling… until then, good ole XHTML for me (too scared to deep-dive into this new technology *just yet*).

  5. Josiah Platt said on

    Awesome write-up. Thanks for sharing this action.

    As your run-of-the-mill developer, coding away under an awning at Starbucks, is there anything I can do to contribute? Anywhere I can go to learn about the potential standards being discussed, and toss in my two cents, or at least just stay up to date on what’s going on?

    I don’t want to muddy the water with my admittedly ignorant suggestions, and I certainly don’t want the next generation of web markup to take longer to arrive than my grandkids might, but I do want to be aware.

    To be honest, this writing is one of the first glimpses I’ve had into some of the real discussions going on about HTML 5. I’ve only been on the outside looking in, drooling over concept pages like the HTML 5 Youtube example.

    I want more. I can has?

  6. Matt Wilcox said on

    Backward compatibility is not an issue, surely? That’s a solved problem and one I think everyone is happy with.

    It’s the extension of HTML that is a problem, because the decisions getting made are, for whatever reasons, not the obvious optimal decisions.

    Bruce’s initial comment was on the new HTML5 functionality to add the semantics of navigation. A way to get across the concept that “this here is navigation, not content”. A simple goal. And one where the solution proposed is inadequate in every single way.

    <nav> is a new element thrown in there, and the logic is that you must wrap any navigation inside that tag. That answers the semantics challenge, but there are a number of fundamental problems with this idea. It’s worrying that arbitrary rules, restrictions and unclear rational used to justify that tag’s behavior have managed to propel it above role=”nav” despite arguments that using role is better in every way.

    The semantics of <nav> are entirely unclear, even by the people that suggested the tag in the first place. It’s supposed to indicate “main” navigation – main to whom? relevant to the page, to the article subject, to the site? To what? No one knows. It’s been defined and re-defined in order to keep it in the spec. That’s the wrong way around. You shouldn’t be re-defining stuff to keep it, it should answer a very clear use case in order to be there at all, and <nav> simply isn’t clear, and it’s mechanics are flawed too. It can’t be used in a <footer> – why exactly? Under what rationale was that rule made? It’s nonsense. <nav> is a stick in the mud, it’s not expandable or flexible for future roles in the way a simple attribute on a tag would be. The argument that “it adds a new element to style” is flawed – if we need such an element then we can add a span or a div which are built for that purpose, but adding a tag where there’s no other need for a tag is pointless. The rules of the tag prohibit the semantics of the tag from being applied in all the places where navigation might be. It doesn’t make sense to nest things all the time.

    You hit the problem bang on when you wrote this: “if the Working Group is open to honest, accurate community feedback”. It’s my experience that it simply isn’t. And it’s not the tech that worries me, it’s the fact that the process doesn’t listen to criticism very well, if at all.

    The HTML WG is as bad as it’s ever been, and while the idea that you can just email them to get your voice heard is great, there is a reason why I hung up my hat and left the Working Group. It’s largely dysfunctional and definitely overly political. That said, it does a better job than the CSS WG.

  7. Chris said on

    Why on earth do we need new tags for header, footer, sidebar, etc.? seems pretty easy and straightforward.

  8. Phil Ricketts said on

    HTML 4 was so loose it allowed us to be very sloppy, and XHTML was great because it brought a tightening that meant websites are built better. Will HTML5 be tight or sloppy? Is there a choice? I’m a bit worried about the perceived lack of direction. I hear all the wonderful things about how it’s going to enable Web Applications and compete with other proprietary rich media platforms like flash – heck native browser video elements are way overdue! There are a lot of contradictions – I’m not on the WG and aren’t using html5 to a large degree yet, but there seems to be so much missing.

    My 2p aren’t worth much on this topic, but regardess, my 2p.

  9. Chris said on

    Oops, was too literal in my previous comment, which interpreted my comment as code! Let’s try again:

    Why on earth do we need new tags for header, footer, sidebar, etc.?

    <div id="footer"> seems pretty easy and straightforward.

  10. Eric D. Fields said on

    What’s next? HTML 6.

  11. XHTML2, HTML5, XML: e l’accessibilità? | biroblu said on

    [...] HTML5, XML: e l’accessibilità? (In attesa di HTML 6…) “As the conversation about HTML 5 and XHTML has played out this week, I’ve felt [...]

  12. HTML 5 « Stevedev Inc. said on

    [...] fascinated by the huge amount of discussion going on right now around HTML 5. Both John Allsop and Jeffrey Zeldman have written some interesting commentary in the last couple of days outlining what they believe is [...]

  13. Mike Whitehurst said on

    If it ain’t broke, don’t fix it.

    XHTML ain’t broke.

  14. Nick Husher said on

    One aspect of this dust cloud that I’ve yet to see anyone mention is that HTML5 “won” because small pieces of the specification offered the potential for vast improvements in the expressive power of the raw web (html, css, and javascript). canvas, introduced by Apple to meet their own needs, represents a significant reframing of what web-standard technologies are designed to do. audio and video, and their associated APIs, are positioned to (when the codec mess is resolved) unseat third-party plugins for presenting rich content.

    HTML and CSS were designed to facilitate document delivery, while the early shift toward HTML5 indicates that developers are growing more and more interested in an application development platform. Scripting APIs are becoming more sophisticated, CSS extensions are focusing on visual designs more often seen in user interfaces than physical documents, and

  15. Michel said on

    I’ll quote Eric L. Epps:

    I, for one, don’t foresee abandoning XHTML 1.0 for developing websites–even if I end up serving them as HTML 5 (and, as browser support continues to improve, adding header, footer, etc. tags).

    That said, since HTML 5 supports XHTML syntax, it makes sense to have some sort of ability to switch between HTML and XHTML syntax, similar to Strict and Transitional. Those who prefer the tighter XHTML can use that, and those who prefer looser HTML can use that–just like we have with HTML 4.01 and XHTML 1 now.

    Actually, a lot of designers/developers in a few other recent posts by Jeffrey here, expressed similar concerns in the comments.

    HTML 5 allows XHTML syntax, but the current Validator does not allow checking for two types of syntax in HTML 5 documents (HTML syntax or XHTML syntax). So if you even create an HTML 5 document and mix in it both syntax styles, your code will be perfectly valid!

    I hope the ability to add distinction between XHTML/HTML syntax, when validating HTML 5 documents, will be soon added. This is a possility, at least!

    Until then, I prefer write XHTML 1.0 and validate it as XHTML 1.0…

    My $0.02:)

  16. devBlog » Blog Archive » HTML 5: Exciting time for web nerds said on

    [...] The story continues this morning with another article on Zeldman’s site. [...]

  17. Design / Upcoming said on

    [...] HTML 5 is a mess. Now what? – Jeffrey Zeldman Presents zeldman.com — 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. More… 0 Comments Share [...]

  18. Tim Wright said on

    I’m very interested in how they plan to integrate RDFa into HTML5

  19. Michael said on

    I don’t think a lot of the design decisions for the new spec are reliant on anything being broken, rather, simplifying the languages. Right now, developers are literally hacking the crap out of their code to make things work properly, which is in comparison to other industries, extremely sloppy. I believe the goal is simply to unify and simplify the usage of the language, for our sake, and with the end-goal: Making the web accessible for everyone to build their own websites not reliant on any proprietary solutions. A very open-source minded goal. Frankly, I don’t believe making things EASIER is a good goal, but making things more logical is.

    I just hope that this advancement will grow our industry and not confuse it. I know I’m excited!

    **There’s a lot of, ‘I think’s’ and ‘I’m guessing’ in my statements, because I’ve unfortunately been ignorant these last few months to the progress they’ve been making. Hoping to change that with the 20 tabs I have open.

    Cheers.

  20. Benjamin Smedberg said on

    If you treat HTML5 as “specifying a new markup language”, then sure, backwards compatibility makes little sense. But one of the primary goals of the HTML5 effort is to precisely define the behavior that browsers should have. Given that people are going to write “invalid markup” from now through the end of time, let’s make sure that all browsers parse and display that markup the same way. There is no invalid HTML!

  21. Zak said on

    I’m a bit surprised the sloppiness of HTML 5 is an issue. It can’t be any worse than HTML 4 can it? And the solution to that is to use XHTML syntax in conjunction with HTML 4 the way we do now. That being said, surely elements like and can be retired. Whatever it takes to get it done, as long as there’s a element I’ll be happy. Isn’t that worth compromising for? Though I’d imagine figuring that out is a whole other equally nasty can of worms.

  22. Zak said on

    I’m a bit surprised the sloppiness of HTML 5 is an issue. It can’t be any worse than HTML 4 can it? And the solution to that is to use XHTML syntax in conjunction with HTML 4 the way we do now. That being said, surely elements like kbd and samp can be retired. Whatever it takes to get it done, as long as there’s a video element I’ll be happy. Isn’t that worth compromising for? Though I’d imagine figuring that out is a whole other equally nasty can of worms.

  23. Anne said on

    … reading your post Jeffrey, I am beginning to think that HTML5 is going to be to XHTML 1.0 and HTML 4.0 what XP is to Vista.

    “They’re damned either way—which almost suggests that the web will be built with XHTML 1.0 and HTML 4.01 forever.”

  24. mattur said on

    We CAN’T just fix HTML every 10-15 years with a 5-10 year process. This is the only shot for a generation.

    We WON’T need to fix HTML every 10-15 years with a 5-10 year process – once HTML5 is finished.

    HTML5 is catching up with all the work the W3C should have done over the last decade, but didn’t.

    When we’ve caught up, and HTML is precisely defined for the first time, we won’t have to do this work again. We’ll have something clearly specified to build *upon*.

    And once we’ve sorted out the foundations of (X)HTML, why not continuously evolve the language with new features – as browsers evolve in the RW? We don’t need no stinkin’ version numbers ;)

  25. mattur said on

    It accepts sloppiness many of us have learned to do without…

    That “sloppiness” (i.e. resilience) is what allows you to use XHTML syntax in text/html documents.

    Worth remembering, I think.

  26. bruce said on

    In answer to your question “HTML 5 is a mess. Now what?” – readers should do as I suggest on my blog post that Jeffrey summarises above: give your opinion to the HTML 5 Working Group. Your participation is actively solicited: http://blog.whatwg.org/help-us-review-html5

    People who don’t vote have no right to moan about the government.

  27. Jeff Croft said on

    For me personally, I’m not all that interested in how these specs evolve. That might make me a lazy designer who isn’t doing his part to shape the future of the web, but I’m pretty content with that. I just want to work with the tools available to us today to make great stuff today. And use the tools available to us tomorrow to make great stuff tomorrow. And so on.

    To that end, I’ve started using the HTML5 doctype for everything. There’s really only two reasons why, and they’re both kind of matters of personal preference more than real-world benefits for everyone:

    1. It bothers my inner nerd a bit to use XHTML without serving is as XML (as we all know why it’s not practical to serve it as XML). Sure, XHTML served as HTML works just fine, but deep down, I know it’s wrong, and that bugs me a little bit. However, I really like XHTML’s stricter syntax. HTML5 lets me use that strict syntax without having to serve a document with the wrong mimetype.

    2. It’s clear to me that HTML5 is the future. Regardless of how good or bad it is, it *is* what’s going to become the de facto language of the web. FOr that reason, I just think it’s nice to go ahead and use the doctype, simply so I don’t have to change it later.

    So basically, today, I’m writing the same XHTML I’ve always been writing, but prefacing it with an HTML5 doctype. It works, it’s valid, and it’s served with the right mimetype. Good enough for me.

    At the same time, I think sticking with HTML 4.x or XHTML 1.x right now are totally reasonable options, as well.

  28. Arlen Walker said on

    HTML 5 allows XHTML syntax, but the current Validator does not allow checking for two types of syntax in HTML 5 documents (HTML syntax or XHTML syntax). So if you even create an HTML 5 document and mix in it both syntax styles, your code will be perfectly valid!

    Michel, go to the validator at validator.nu, click “more options” and check out the “preset” dropdown. You should find what you need there.

  29. Neal G said on

    None of this really matters until:

    1. IE supports whatever new standard we decide on
    or
    2. IE no longer has the majority of the market share

  30. Left-wing Esperantist said on

    There are right-wing Nativists who speak Esperanto.

    And there are many web developers who are already using things completely incompatible with HTML (Flash, Silverlight, and sometimes XUL)

  31. Holly Fortenberry said on

    The new spec should NOT allow sloppy syntax.

  32. Billee D. said on

    Awesome reading. My suggestion to either group is to get together on the spec and stop the pissing contest. HTML 5 can be a great next step, but I am starting to question some of the proposed implementations. For example, do we *really* need all of these new attributes or can POSH with semantic class names suffice?

    The bottom line is that nothing should be engineered to make everyone happy. The best products/services in the world are generic enough to keep most people happy, but specialized enough to get things done. Future-proofing HTML seems to me to be somewhat akin to anticipating an alien invasion. You’re never going to be fully prepared. Just keep things simple and engineer for the present. Just my 2px…

  33. Steven Clark said on

    To be perfectly honest, the reason why I’ve practically given up on the HTML 5 debate (some time ago) is simply the perception this is Ian Hickson’s specification as evidenced by the HTML 5 reaction to the ideas of accessibility some time ago. So, while I guess I can’t complain about the government because I have not been voting, there’s no point voting in a despotic regime that is doing whatever they personally feel is their greatest personal legacy.

    Also, I got tired of really nasty people sending me almost illegal hate mail on these subjects – hardly a professional approach to doing business. Some of them would probably border on obsessive psychological disorders, to be honest.

    Anyway, just how I feel. So I’ve tended to be plain accepting that HTML 5 will be whatever it is, and if its bad its bad because of Hickson and a certain crowd. I have no power to affect the obsessive thoughts of certain individuals one way or the other. I’m also probably representative of quite a large group of the silent disenchanted who will continue to code in HTML 4 or XHTML 1 well into the future and fight on building websites in whatever tag soup monstrosity we are burdened with on the day.

    Two working groups on the one spec… we could even come back a step and ask ourselves whether we think design by committee is even possible in our own small workshops? No, probably the worst thing to use is a committee. So why is there an expectation two committees which can over-ride each other is going to work?

    Just a suggestion. Stop the committees. Disband Hickson’s group. Other than that, the horse has bolted. If HTML 5 is a crock then its one that’s wasted a generation. At this point what is there to do, realistically? Start again? Won’t happen? Divert Hickson? Won’t happen.

    Just my two cents in passing Jeffrey.

  34. J David Eisenberg said on

    The smart people like real application frameworks, like Flash, Silverlight etc. HTML will always just be a bastard child of real programming languages.

    First, HTML is markup, not programming; it never pretended to be otherwise. IMHO, HTML is the great equalizer; it permits everyone to get a presence on the web with a very low barrier to entry. Just a few hours (or less) of work, and you can share your knowledge and passion with the rest of the world–no programming experience necessary.

    I think there will always be a place for that.

  35. Steven Clark said on

    pleemlup – markup and programming are simply two layers of technology… would you suggest that you are going to program what to make your web page appear in a browser – right, you’ll programatically output HTML. Or something. Because programming interfaces without markup – Java Interfaces, for example, as in the View part of Model, View, Controller architecture – is a lot harder to learn to do well and more specialised than using HTML markup on the interface coal face.

    Instead of seeing programming as the square peg answer for every shape hole, sometimes it pays to use the right technology for each job.

    But here here, said like a true programmer lol. When you only have a shovel, how do you clean the windows? Cheers. :)

  36. HTML 5, Ego and Design by Committee : StevenClark.com.au said on

    [...] Its fine to have contrary opinions, but the HTML 5 conversation is getting a lot of steam over on Jeffrey Zeldman’s site this week and its probably important that people all have their say. Whoever we are, wherever we [...]

  37. jeremy said on

    I just don’t understand why both groups don’t just admit failure and scrap what they’ve done (which is admittedly brilliant – and completely wrong), then join up to create something more logical AND more useful/usable? Oh right – ego.

    There MUST be a better way to meet the future.

  38. Ralph said on

    The combination of CSS, JavaScript, and XHTML 1.0/HTML 4.01 is here to stay, and while the web 10 years from now may offer features not supported by this combination of technologies, we need not fear that these technologies or sites built on them will go away in the decades to come.

    That’s sweet music to us wide-eyed little folk who peep between the legs of ye Colossi.

    Honestly, it’s good to hear, because this debate seems like a train out of control, and while I’m not sure I want to be on it, I also don’t want to be left behind.

  39. Damien Buckley said on

    All I can say is that 5 years after reading DWWS for the first time, I’m glad and relieved that Zeldman is here deciphering the nonsense, standing up for the sensible ground and keeping it real. Stick with it – millions of designers worldwide are relying on you to make sense of it for the rest of us.

  40. Erin Lynch said on

    I would like to see the process evolve in baby steps. I think the first decision that needs to be made (and appears to already have been decided) is are we developing a new HTML or XHTML spec. Once that is done, then get down to the business of developing portions of the spec (reach for the low hanging fruit that has complete buyin). Forget about reaching for the brass ring of a complete HMTL 5 spec at this point-go for what’s attainable. Get consensus and buy in from all involved on portions of the spec and release them in iterations. I mean we went from HTML 4.0 to HTML 4.01, right?

    There is too much emphasis being put on getting a spec written that will accommodate the web for years down the road, when, in reality, we are not sure where the web will be in 6 months. By releasing portions of an agreed upon spec in phases (HTML 4.1, HTML 4.2, etc.), you make progress towards a complete HTML 5 spec, while constantly extending the toolsets available to developers/designers.

  41. Edgar Leijs said on

    ‘they’ said to buy ‘Designing With Web Standards’, so i bought the first and second edition. It taught me to write tidy, lean and mean. I thought i was writing forward compatible, you know, progressive? In my indoctrinated mind, HTML is backwards and will stay backwards even with HTML 13! (…sound of the Jaws theme…)

    XHTML 2 will be beautiful, CSS 3 fascinating and JavaScript en ActionScript will emerge to a SuperScript…. but then i woke up…

  42. Lars Gunther said on

    I can’t believe people’s fixation about nav, section, header and footer. HTML 5 brings so much more. Drag and drop – you don’t like that? Data-attributes, that don’t break validation, no good for you? Native video and audio gets me excited. Why not you? (Yes, we all wish Apple and MS would leave their monopolistic agendas and get behind ogg/theora/vorbis, but even now it is a step in the right direction.)

    And we have client-side storage, getElementsByClassName, additional form widgets and ruby. There is no ruby in in HTML 4.01 or XHTML 1.0. Sorry all people in Japan and other places that might benefit. The web developers of the world seem to an alarmingly high degree content with using technologies from 1997. And proprietary plug-ins.

    Here is an idea for all people who do not like section, nav, aside, header, footer, and the devil’s mother – don’t use them. All your divs will continue to work just fine. It is not like anyone is forcing them down your throat. But do not block HTML 5. It brings a ton of much needed upgrades!

  43. HTML 5 Weekly Review #3 | Jeff Siarto said on

    [...] was another slow week on the HTML 5 spec front but not with­out some great dis­cus­sion from the Zeld­man camp. In lieu of any real break­ing news, I’ve pro­vided some [...]

  44. Geoffrey Sneddon said on

    A lot of people are saying there should be no sloppiness allowed in HTML 5, but the biggest issue with this is simply managing to define what is sloppiness. People have greatly disparate views about what sloppiness entails.

  45. David Hucklesby said on

    Before the days of desktop computers, we wrote documents in some variant of SGML. HTML was intended to be a simplification, usable by non-technical people.

    HTML’s success is due, I believe, because it achieves that goal. Most web sites are a tag soup of invalid code. But they work! Let’s get real. A strictly formed language that breaks on an unescaped ampersand will never be used by the majority of people who write web pages. As for those “purists” who trumpet the strictness of XHTML while delivering their pages as HTML, I can only wonder…

  46. Ross Kendall said on

    The only reason developers such as myself serve up XHTML as HTML is because we are waiting for crap browsers to catch up! Do you think it will be any different with HTML5?? (Maybe in 10 years IE will support HTML 5 properly… and application/xml)

    As for what features HTML 5 has, I care about having a good approach for creating semantic documents more than flashy app features. Good semantic information will outlast any app.

    Also, I think the limitations of CSS bother me more than the limitations of HTML.

  47. Ф@kazuhi.to: links for 2009-07-17 said on

    [...] to position elements on the page in three-dimensional space using CSS." (tags: css webkit) HTML 5 is a mess. Now what? ? Jeffrey Zeldman Presents The Daily Report "The combination of CSS, JavaScript, and XHTML 1.0/HTML 4.01 is here to stay, and while the [...]

  48. Terraplane » Blog Archive » 15 Really Useful Web-based HTML Editors said on

    [...] HTML 5 is a mess. Now what? (zeldman.com) [...]

  49. Wayne State Web Communications Blog » Blog Archive » [Friday Links] The CSS3 Edition said on

    [...] HTML 5 is a mess. Now what? Jeffrey Zeldman Presents The Daily Report [...]

  50. me said on

    Lately a lot of standards evangelists of the old days (the 90s) are falling for HTML5, it feels like they’re tired of fighting for the best solution, and they settled for a mediocre one…

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

    [...] blog, the debate whether HTML 5 working group is heading towards the right direction or not is getting pretty nasty. A guy called John Allsopp commenting on Zeldman’s blog, explained why “HTML 5 is a [...]

  52. Ronald's Website - News Feeds said on

    [...] HTML 5 is a mess. Now what? A few days ago on this site, John Allsopp argued passionately that HTML 5 is a mess. In response to HTML 5 activity leader Ian Hickson's comment here that, "We don’t need to predict the future. When the future comes, we can just fix HTML again," Allsopp said "This is … [...]

  53. Veronikan said on

    HTML’s success is due, I believe, because it achieves that goal. Most web sites are a tag soup of invalid code. But they work! Let’s get real. A strictly formed language that breaks on an unescaped ampersand will never be used by the majority of people who write web pages.

    No, people will do what’s required of them, and in a lot of cases it’s much easier when there is a clear set of rules to follow. The lack of a decent and reasonable standard for mark-up causes more work for those on all the other levels of delivering content via the web. It is wasteful, inefficient, and will impede progress. Developers wouldn’t be using XHTML delivered as text/html if this weren’t the case.

    I say use this generation to once and for all establish a basic set of standards for writing mark-up.

  54. Veronikan said on

    And I’ll be the first to learn it as I did not implement the XHTML properly in my comment above. My words begin in paragraph 2.

  55. Weekly digest of week 29 2009 | Capping IT Off | Capgemini | Consulting, Technology, Outsourcing said on

    [...] HTML 5 is a mess. Now what?HTML5 and The Future of the [...]

  56. Web Creative from Leeanne Lowe said on

    [...] 20 Jul 2009 HTML 5 is a mess. Now what? [...]

  57. Web fonts, HTML 5 roundup – Jeffrey Zeldman Presents The Daily Report said on

    [...] HTML 5 is a mess. Now what? A few days ago on this site, John Allsopp argued passionately that HTML 5 is a mess. In response to HTML 5 activity leader Ian Hickson’s comment here that, “We don’t need to predict the future. When the future comes, we can just fix HTML again,” Allsopp said “This is the only shot for a generation” to get the next version of markup right. Now Bruce Lawson explains just why HTML 5 is “several different kind of messes.” Given all that, what should web designers and developers do about it? — 16 July 2009 [...]

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

    [...] HTML 5 is a mess. Now what? [...]

  59. The Truth About DOCTYPE | J Cornelius said on

    [...] enough to be able to ignore IE 6, HTML 5 is fine, too. The merits and perils of each have been thoroughly discussed elsewhere. The people pushing the debate are all very well qualified, have lucid [...]

  60. RSS Reader Picks #9 | JortK.nl said on

    [...] HTML 5 is a mess. Now what? Google Chrome Operating System: the Facts and Fallacy HTML5 and The Future of the Web Google Fusion Tables and Publicly Available Data Share and Enjoy: [...]

  61. austin cheney said on

    From a technology perspective the web is a failure and that failure is becoming quite clear.

    1) The intent of a markup language is first structure and second semantics, for which semantics is absolutely reliant upon structure. HTML has always largely failed at this for a purist perspective and unfortunately HTML 5 takes two steps backwards by favoring SGML implementations over XML serialization and by being inherently a practice of usability and not semantics. Semantics is not an exercise in usability and rarely do the two practices ever intersect.

    2) The web is insecure. With regard to all of computing ever the web is the most insecure thing ever without anything else even providing the most remote comparison. JavaScript is significantly, though not entirely, to blame for this. This problem is only getting progressively worse and the only cure is to either break HTTP or forbid client-side scripting. Neither of those are acceptable, so the web is quite simply broken.

    3) HTTP is a model of simplicity. In computing this is a good thing, but in security this is a bad thing. HTTP is nearly perfect at what it does and seeks to do nothing more, which is also typically a great thing. Unfortunately, this supreme simplicity does not provide the conventions of sophistication necessary to address so many of the concerns and wishes that are necessary for modern user experiences, cross-web application interactions, or cloud computing. The needs of these feature cannot be met by HTTP as a medium of data interchange.

    Since data on the web never fully achieved the structure it was intended as the most primitive component of the web, and the web is a hopeless insecurity disaster, and has finally about to collide with its own technology limitations it must simply be abandoned as a model for data interaction.

    Fortunately, email does not have these problems even though it is a dinosaur of computing that is continually defying extinction. Email does not have any standard convention for describing content. The standard simply does not exist, which is astonishing. This is a great thing, because it means somebody can create a markup language from scratch that does not have to be backwards compatible to anything and can be completely independent and built correctly for semantics the first time. If such a language were ever adopted the security solution for client-side scripting has already been published: http://www.ietf.org/id/draft-cheney-safe-00.txt

    We really don’t have to keep using something we all know to be broken. We can make something better. If anything this broken existed for commercial implementation in any other industry people would go to jail for criminal negligence, as they have for significantly less incompetent malfunctions. Honestly, we use the web buy things and transfer funds even though its the most flawed security equipment ever created. Do you find that rational?

  62. HTML5 Resources & Discussion « Cloud Four said on

    [...] HTML 5 is a Mess. Now What? [...]

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

    [...] HTML 5 is a Mess: Now What? (Jeffrey Zeldman) [...]

  64. Drag and drop en HTML 5 | bbxdesign said on

    [...] si le HTML 5 est encore un joli bordel, des développeurs s’en donnent à coeur joie pour trouver des fonctionnalités très [...]

  65. royAkiyama's Bookmarks on Delicious said on

    [...] HTML 5 is a mess. Now what? – Jeffrey Zeldman Presents The Daily Report SAVE [...]

  66. Rhy said on

    @Lars Gunther

    I haven’t done enough reading of the HTML 5 spec yet to be fully informed, despite my resolution. I’m starting at the beginning and working my way through.

    But I completely agree that there should be more focus on aspects of HTML 5 aside from header, footer, and nav. I think the “features” like drag and drop, etc. — the entire “web application” section of HTML 5 could well explain the deficiencies of HTML 5.

    Web applications are a different beast. Replaced elements do not deal well with CSS (and due to the reasons for that, I don’t think they ever well). Semantics in web applications are a fuzzy issue. And accessibility in web applications is even more difficult than in a static HTML webpage.

    Will someone please explain to me why drag and drop, etc. should be implemented within the HTML spec? Is this HTML or a competitor to Flash/AIR/Silverlight? I like having semantic elements, and I can imagine updating an HTML 5 progress bar with Javascript. Could be cool–but I just don’t know.

    Basically there is a crap-ton of stuff in HTML 5, some of which doesn’t make much sense, much of which fails to consider providing accessible alternatives and meta information, and the bulk of which is not being addressed in the public fora.

    I suppose there could be enough individuals in the working group to handle all of it, but with all this to address: new semantic tags, changes to old tags, new web app tags, and new functionality focusing on web apps, the need for accessibility, the desire for meta information…there’s a lot of places for logical failures to occur and too many competing things to focus on.

    What’s worse is that I always find that it is only through using code in realistic use-cases that I find deficiencies. Reading a spec on a theoretical level just doesn’t do enough for me. And I won’t be able to use all of that stuff, especially since so much of it isn’t implemented. That concerns me and limits by ability to really comment on an informed level.

    @ Jeffrey Zeldman
    Your validation claims my e-mail address isn’t valid, but I assure you it is. I know .name domains aren’t really popular, but…

  67. Jeffrey Zeldman said on

    Your validation claims my e-mail address isn’t valid, but I assure you it is. I know .name domains aren’t really popular, but…

    Off-topic, but there is a known issue with some .name addresses. The system is configured to accept them, WordPress accepts them, the mail script accepts them. We don’t know why the system rejects some .name addresses; it may have to do with an overly touchy third-part spam blocker.

  68. HTML5 Canvas demo | XHTML og CSS | MultiMedieForum.dk said on

    [...] 20:54 Men som den mavesure gamle nar jeg til gengæld er, vil jeg gerne opfordre folk til at læse http://www.zeldman.com/2009/07/16/html- … -now-what/ og ellers bare få tilføjet zeldmans blog til deres RSS readers – Han har skrevet en del omkring [...]

  69. six03 » HTML5, DOCTYPES & MIME Types said on

    [...] HTML5. I’ve played with the beautifully hand-crafted tags, read the articles from my friends Jeffrey and Bruce. Those throw me for a loop. XHTML2 seems to be a dead issue, I know I said I’d [...]

  70. HTML and blogging at onemilestories said on

    [...] the underpinnings of the entire internet within a few years’. Although some others are not as enthusiastic. And not all browsers support it yet. (For those of you who are statistically and bigpicturally [...]

  71. Sam Ruby’s Comments said on

    [...] 5 is a mess. And I ponder what we should do about it. Moving forward, compatibly…. Excerpt from Jeffrey Zeldman Presents The Daily Report 21 [...]

  72. HTML 5 + CSS 3 = une révolution pour les interfaces web > FredCavazza.net said on

    [...] pas possible (qui provoquent d’innombrables querelles d’experts depuis des années : HTML 5 is a mess. Now what?) sans pour autant prendre partie car de toute façon les choses semblent visiblement [...]

  73. HTML 5 is a mess. Now what? said on

    [...] Thierry.Lefort via zeldman.com Submitted: Sep 10 2009 / 06:09 HTML 5 is a mess. Now what? A few days ago on this site, John Allsopp argued passionately that HTML 5 is a mess. In response to [...]

  74. HTML5 Is A Mess, Now What? - The Delmarva Group, LLC said on

    [...] HTML5 Is A Mess, Now What? Friday, 11 September 2009 09:17 |    HTML5 Is A Mess, Now What? [...]

  75. Hacker News said on

    [...] Brown apologises to Alan Turing (telegraph.co.uk) 107 points by sharpn 1 day ago | 26 comments44.HTML 5 is a mess (zeldman.com) 21 points by nreece 11 hours ago | 7 comments45.Dropbox enables effortless upload to [...]

  76. Squirrel Hacker » Daily Digest for September 12th said on

    [...] Shared HTML 5 is a mess. Now what? – Jeffrey Zeldman Presents The Daily Report. [...]

  77. Brad said on

    Funny to see this kind of turmoil about code structure so soon after a big todo about code behavior, ala ecmascript 4. I wonder why they didn’t just dilute xhtml2 with a little html5 practicality the way that JavaScript 2 softened into EcmaScript Harmony? I was expecting a compromise, not a duel.

    If you follow the rule of threes, we should be expecting a CSS bloodbath soon. I think think I’ll take shelter in XML/XSLT until this all blows over. Browser sniffing is making a comeback!

  78. Người Tập Viết » HTML 5 is a mess. Now what? – Jeffrey Zeldman Presents The Daily Report said on

    [...] HTML 5 là một mớ hỗn độn HTML5 được phát triển để thay thế cho phiên bản XHTML2 vốn đang sống trong một thế giới hoàn toàn khác. Nếu như điểm yếu của XHTML là đi quá xa so với thực tế, HTML 5 lại áp dụng quá sát những gì trong thực tế. Nó chấp nhận bỏ qua sự cẩu thả mà rất nhiều trong chúng ta đã làm theo thói quen (và như một hệ quả không khuyến khích những người chưa biết gì về chuẩn học và tìm hiểu thêm về nó). [...]

  79. IRC log for freenode/#scheme #[date 458741000 12 46 22 13 9 2009 0] said on

    [...] [...]

  80. Blog Công Nghệ: Liên Kết: HTML 5 là một mớ hỗn độn said on

    [...] hiểu thêm về nó).Thảo luận trên Người Tập ViếtXem đầy đủ bài viết tại http://www.zeldman.com/2009/07/16/html-5-is-a-mess-now-what/ Được đăng bởi Blog Nhanh vào lúc [...]

  81. Where now for the web? HTML5? said on

    [...] HTML5 is a mess. Now what? by Jeffery Zeldman [...]

  82. Designer vs. Developer « [ LABORATORY NOTES ] said on

    [...] specs are improvements, even if they do mean longer code and *gasp* more learning! (Okay, the whole XHTML/HMTL5 debate will have to wait for another day. There are exceptions to every good [...]

  83. demaree.me, Jeffrey Zeldman: "HTML 5 is a mess. Now what?" said on

    [...] Jeffrey Zeldman: "HTML 5 is a mess. Now what?" » Less an opinion than a summary of the discussion that’s flared up since XHTML2 was killed [...]

  84. Accessibilità » Blog Archive » XHTML2, HTML5, XML: e l’accessibilità? said on

    [...] by admin on gen 8, 2010 (In attesa di HTML 6…) “As the conversation about HTML 5 and XHTML has played out this week, I’ve felt [...]

  85. Agence Web Comevents » HTML 5 + CSS 3 = le futur du web said on

    [...] un foutoir pas possible (qui provoquent d’innombrables querelles d’experts depuis des années : HTML 5 is a mess. Now what?) sans pour autant prendre partie car de toute façon les choses semblent visiblement [...]

Comments off.