The WHATWG Blog

Please leave your sense of logic at the door, thanks!

HTML is the new HTML5

by Ian Hickson in WHATWG

In 2009 we announced that the HTML5 specification at the WHATWG was progressing to Last Call. The plan at the time was to finish the specification this year and publish a snapshot of "HTML5" in 2012. However, shortly after that we realised that the demand for new features in HTML remained high, and so we would have to continue maintaining HTML and adding features to it before we could call "HTML5" complete, and as a result we moved to a new development model, where the technology is not versioned and instead we just have a living document that defines the technology as it evolves.

As there is still interest in publishing a snapshot of HTML5, the W3C is still working on that (in conjunction with the WHATWG).

Because the specification is now a living document, we are today announcing two changes:

  1. The HTML specification will henceforth just be known as "HTML", with the URL http://whatwg.org/html. (We will also continue to maintain the Web Applications 1.0 specification that contains HTML and a number of related APIs like Web Storage, Web Workers, and Server-Sent Events.)
  2. The WHATWG HTML spec can now be considered a "living standard". It's more mature than any version of the HTML specification to date, so it made no sense for us to keep referring to it as merely a draft. We will no longer be following the "snapshot" model of spec development, with the occasional "call for comments", "call for implementations", and so forth.

In practice, the WHATWG has basically been operating like this for years, and indeed we were going to change the name last year but ended up deciding to wait a bit since people still used the term "HTML5" a lot. However, the term is now basically being used to mean anything Web-standards-related, so it's time to move on!

If you have any questions please don't hesitate to ask them in the comments or on IRC. We'll update the FAQ with the most commonly asked questions.

↔

152 Responses to “HTML is the new HTML5”

  1. It’s funny – I was just saying yesterday that HTML5 was going to be the last numbered version, and that HTML was moving to an unversioned model, but couldn’t find the link. This is definitely a good move, the HTML5 movement has gone a little mad and started to include anything remotely related to standards. Things like HTML don’t need numbers. It’s not as if browsers implement the whole standard in one go anyway.

  2. What am I gonna do with all the HTML5 t-shirts I just ordered?

  7. Quinn: years from now you’ll be able to wear those shirts and have younger devs approach you and ask what “HTML5” is, and you can tell them the tales of woe and triumph that surrounded the name!

  8. I assume this just means that new features (that may only be tangentially related to “HTML”) can be added to the spec at any time. If this “living document” approach means a browser can implement a feature and then the feature’s spec is changed after the fact, that is not good. Otherwise, it makes sense. The term was getting pretty bloated and vague, like NoSQL.

  10. So HTML is the new HTML5, HTML5 is the new AJAX, FlashPlayer is the new Java, MPEG-4 is the new QuickTime, SVG is the new PNG, Facebook is the new AOL, iOS is the new Mac, Android is the new Windows, and WHATWG is the new W3C. Got it!

  11. Like many others… I’ve spent the last year saying “Within a year or two, people will drop the 5 and it will just be HTML.” Glad WHATWG recognizes that has to happen. The idea of HTML5 is important because people need to recognize that there are major new features. But the goal is to forget that HTML5 is “something special.”

    And yes, the same thing should be said about Ajax. The term was useful to help people to understand that there were latent capabilities in Javascript that nobody was taking advantage of. With apologies to a few bloggers, the term Ajax is much less frequently used, and it’s just “cool stuff you’re expected to know how to do in Javascript if you’re competent.”

  12. @Jimmy — our focus on backwards compatibility is still ever-present, and extends to making sure that the spec remains compatible with implementations once they ship. In fact, we keep very close contact with browser vendors to make sure that we don’t change things people are depending on.

  13. This is good. HTML doesn’t need a versioning system. It’s more pragmatic than that.

    @darren, I couldn’t agree more.

  14. Isn’t it advantageous to make snapshots now and again though, even if those snapshots are now a posteriori? I applaud the move in principle, but am not sure of some of the implications – don’t browsers need a target to work their implementations towards, even if it’s a snapshot that is essentially arbitrary?

  15. This is going to be a complete disaster for marketing-centric companies, and I for one think it’s a great move.

  16. Sounds like a realistic approach, and in keeping with other development practices that modern high levels of connectivity have reshaped (iterative development, DVCS, etc). Monolithic approaches are seeming less and less practical.

  17. What Douglas Greenshields said. If you do not publish snapshots every now and again, you are Orwellian in your recognition of the role the mistakes of the past play into the present and the future.

  18. Maybe something more granular than full point revisions is advised, but a “living standard” is a disaster. How do we know what to use, without having some sort of snapshot that browser can aim at and developers can evaluate? Say I want to make sure that 95 percent of my visitors or 70 percent or whatever can use my website as designed, with my spending hours coding up fallbacks and all that crap? How do you make a test suite and a browser compatibility chart for a “living standard”? It sounds like HTML is becoming a sort of Wikipedia revision style chaotic nightmare.

    I have a feeling there is a “rest of the story” to this blog post. Some sort of internal pissing war with the W3C, perhaps?

  23. Snapshots? All the specs on this site are kept in version control, and there’s a link to it at the beginning of each one. Don’t bother name-calling if you can’t even be bothered to look at the specs you’re criticising.

  24. IN OTHER NEWS: Paul Irish & Divya Manian to drop the ‘5’ from their ‘HTML5 Boilerplate’ as soon as they can find the guy who owns ‘htmlboilerplate.com’ and buy it from him

    Seriously though, I really like the HTML5 logo and branding. I’m going to keep using it I’m afraid. I’ll be the old guy in the rocking chair, playing his cheap Ukulele shaped like the HTML5 logo, bought at a second-hand store for £2.50, saying “ITS STILL CALLED HTML5, DAMNIT”

  25. Great news! Time to stop the useless hype and “i am more HTML5 that you” debate.

    p.s.: sorry W3C, you are too slow, as always, and your HTML5 logo is obsolete 1 day after presentation 😉

  26. I don’t understand this at all. Isn’t the whole point of a specification to establish fixed point of reference so that all parties implementing the standard can ensure they have a common baseline of compatibility?

    If you’re continuously changing the specification while maintaining the same identifier, doesn’t this completely defeat the purpose of having a specification?

  29. How about we take it one step further. The web really is a living document, so we might as well just call it “stuff on the web” instead of HTML. Makes more sense, really, and it is broad enough to encompass any future changes and evolution of stuff on the web. Or maybe we could name standards after what certain browsers are capable of… for example, this part of the web is Internet Explorer x friendly, while that other part of the web is Firefox x.x friendly, etc etc.

  30. Cute, but this won’t stick, for good or bad. HTML5 is too useful of a milestone to wash over and future web standards will require similar identifiers.

  32. “Living specification” sounds like a draft that may and will change at any moment and is probably not even complete at any moment of time but is still called a “specification”, since that sounds cool, technological, and impressive.

    I can’t believe I feel the need to explain such a trivial thing, but really, a “specification” is a complete, consistent, stable, and published normative description. It can be cited and referred to as a requirement, e.g. in contracts and product descriptions. Typos, apparent mistakes etc. can and should be corrected, but the content is not changed as you go just because someone or some committee changes its mind. The specification definitely does not “live”; its life is in serving various purposes _as it is_. Development work takes place elsewhere and may eventually lead to a new specification.

    So “living specification” is about as oxymoronic as you can get.

  34. To clarify, browser vendors (like Opera, where I work) have no use for snapshots. We’ll always look at the latest version of the spec, and things that have already been implemented and shipped aren’t going to change in any radical way. So there’s no need to worry about us!

  35. Niels, the use of DOCTYPEs for validation purposes was dropped a long time ago. The DOCTYPE is now simply be <DOCTYPE html> and the validator should now just validate according to the latest requirements it supports, or possibly a manually selected validation profile or schema, depending on the validator.

  36. This seems like kind of a bad idea, implemented more to screw over the W3C in the wake of their logo release than to actually help anyone do anything. What’s the point of a standard that isn’t standard? What’s the point of having a doctype to verify against if the doctype can be updated at any time? I can write a browser that supports HTML rendering on Tuesday, and by Thursday my browser can no longer handle standards-compliant HTML.

    TL;DR: This is not how standards work. You are a standards group, you are supposed to be better at standards than this.

    If you want people to be able to write to and use the HTML “trunk”, then offer that, but don’t neglect the importance of stable releases.

  37. Guys, with all due respect, this is irresponsible. Your job as a standards body is to publish stable standards after they pass all required phases. Browser vendors should be able to develop to a certain version of the standard. Instead of having a ‘dev/stable’ thing, you’re going the Wikipedia way and saying ‘The nightly build IS the standard’.

    Only unlike Wikipedia articles, specs tend to have consequences. Do we really want Firefox 4 to ‘support the html standard as of 2/2/2011 03:59 GMT’? This pushed browser vendors to implement half-assed features of the spec, and therefore halts the ability to do proper feature-detection, hence the Firefox autobuffer incident: http://hacks.mozilla.org/2010/08/video_preload_attribute/

    We developers and our creations are ‘the living web’. WHATWG and W3C don’t have that privilege. I’ve read everything here and on the FAQ, and this doesn’t make any sense to me.

  38. If I write a valid HTML4 document – with a DOCTYPE – then that document will always be valid and any HTML4-standard-compliant client will be able to render it. Isn’t it the case that this only holds for nu-HTML if *nothing* is *ever* deprecated/removed?

  39. I don’t agree with this move – unless it means that “HTML” is everything related to markup while “HTML5” is the wider term (but I know how many people hate this concept) that includes all the “new stuff” (geo, sockets, multimedia, css3 – but sorry, under a users (and 99% of developers) perspective it’s clear that all the “new stuff” is bundled together)

    So my question is: from now on what does it mean that a site is “HTML”? HTML pages out there are still mostly full of tables, <font>, <b> and <i> tags – is this the same “HTML” that uses semantic tags, canvases, and CSS3?

    I think having a new term that helps understand how a site uses new technologies and a new approach to the web (“app centric”) in contrast to *older* technologies and implementations is very useful for the users and for the technology itself, even if this means that the High Priests of the Virgin Nomenclature have to take a (little) step back.

    All this, IMVVVHO.

  40. WHATWG why are you indecisive? it’s common sense.

    You’ve been promoting HTML5 for a few years now as “HTML5”. People want to learn it, they want to talk about it, because it’s defined it spreads, you could have called it “HTML poo” it would still work.

    Now!!! If all users had browsers that self-update to support new languages/standards released in unison, it would make sense to consider this version of HTML as simply “HTML” as every browser would support it.

    But at this moment in time that’s not the case. Everyone’s browser doesn’t supports HTML5 so we need to “class” it to:

    know the difference,
    to encourage people to learn it (whilst learning 4.1 + XHTML),
    To encourage the use of CSS3 by the majority of people who confuse HTML5 for CSS3 (hey it works).

    It would be logical to make this move at the time when IE8 is near death.
    Then we’re all laughing and you can call it what you want, HTML/HTMLpoo/H whatever.

    But WHATWG you’re not “Prince”

    This is not “The mark-up formerly know as HTML5”

  41. For most of the last 17 years HTML has been a retrospective standard. So really this is not new.(remember Netscape’s tag)

    However to validate against a standard you need to have a clear way of demonstrating at which point you validated. Presumably we as Dev’s will just say it was valid at time of publishing.

    Is feels as if this is just the acceptance of the reality that the pace our indusrtry innovates and develops makes it impossible but to work in any other way apart from a ‘living’ standard.

    It cetainly looks from the outside like we moved from ‘Browser’ wars to ‘Standards’ war, W3C v WHATWG

  42. Wow, this is great! Like Google Chrome: No more numbers, just ongoing development, improving and evolution. Welcome to the 21st century!

  43. Gary is quite right. Those who cannot remember the past are condemned to repeat it (fortunately I can remember what I said about Netscape, and it’s on record anyway 🙂 The point is, quite frankly, m’dear, it doesn’t actually matter whether HTML[5]* is a free-for-all (aka “living format”) or a snapshot.

    Web pages are driven by Marketing, and if Marketing believe they need HTML to contain blink or next week’s hot video format then they’ll do what is needful to get it. It’s not important because no-one could care less about those pages so long as they look pretty, because they are transient, their information content is virtually zero, and they don’t even have to work in all browsers, least of all validate. And it’s not important for Marketing if their requirements affect the web for other people.

    Back in the Netscape days, businesses were actually paying for browsers directly, so they got to say what went in. Now they’re paying indirectly, and other corporate interests have other leverage, but the net result is the same: the specification of HTML is not important because browser-makers will implement whatever who leans on them heaviest wants, regardless of whether it conforms to any kind of standard. It’s been useful in the last decade that they have indeed produced some kind of conformance, but that hasn’t exactly been a priority: it’s been much more about pandering to the egos of the participating organisations, believing they can “control” the web by controlling browser support and HTML content. That is a much riskier and more serious affair altogether.

    All the important data nowadays is behind the scenes, in databases or XML documents, and can be exposed as RDF triples or in whatever other feed format du jour is needed. It’s not important because the effect of an ungoverned HTML is that both browser-makers and page-makers can invent whatever markup they like, and whoever shouts loudest wins. Designers and engineers are still going to need more and better tools, more and better training, more and better support, and more and better documentation, just in order to keep pace, so those industries providing it are going to have to keep pace too.

    It’s just business, guys. Get used to it. HTML long since ceased to have any intrinsic meaning: that moved to XML 15 years ago. It seems that the Clue Train has been making regular stops, but only a few people ever took a delivery.

  44. It’s better to split the big HTML5 specification in modules, define which modules belongs to HTML5, HTML6, … and which modules are stable and which are drafts.

    So that there is a clear specification that could be implemented and used.

  45. If you don’t get it:

    The browser vendors have decided long ago to take over control of HTML. They are the ones implementing HTML, so there decision is a understandable one. MPEG works the same way in this regard.

    Ian specs anything that the vendors agree on to implement. So the spec is nothing but a documentation of the current and the soon-to-be implementations. The vendors have no need for versioning, so it’s gone.

    Anyone who’s unhappy with this can make his own versioned spec and hope the vendors will honor it. They probably won’t, ’cause they are already busy looking at there own spec. Of course you can try to become a browser vendor with big market share too. That might improve your chances for the others to listen.

  46. I think it’s too bad, as fuzzy as it may have been, “html5” was a good rallying cry to increase cross-browser compatibility and features. You can’t do that with “html” (my IE 4.0 does that!) and people are going to fall asleep with “the latest cross browser standards and technologies, including …”

  47. Why not speak up with this “URGENT” announcement before people were writing about HTML5?

    I will continue to refer to HTML5 as HTML5 until it is regular practice. You’re timing is horrendous, and quite frankly, annoying.

  48. So, what part is “living” and what is “mature”? Now that Google pulled h.264, are we going to reinvent the video tag? What does it take to get things “living”, aka discussed for change?

    As said above, you need to define what modules, or sections, or whatever, are NOT up for debate and make that crystal clear. This means that you’ll have 100% compliance in those tags. Then the parts that are “living” can be hashed out among first-adopters, browser creators, and the so-called marketplace.

  49. Finnaly people start to actually refer to HTML5, Finnaly people start to talk about it, the buzz is high and boom. it’s all back to the old HTML. I’m not sure if this is the right moment right now. Coudve waited another 6 months or a year.

  50. An unversioned model? Are you kidding me? Is this because HTML5 is not ambiguous enough? I realize that HTML has been operating this way in practice for years, but that’s exactly what’s wrong with it and why there is so much variation between browsers! Some browsers implement a spec early and have to leave in support for legacy code (Firefox), and others implement their own spec and ignore the official one (IE), while others keep changing with the spec and don’t care what websites they break (Chrome/Safari).

    What is needed is more strict versioning. As a developer, I need to be able to specify that a website was built using a specific version of HTML/CSS/JavaScript and then not have to worry about that site breaking in 6 months.

    This will only cause more work for everyone–specifically developers. Thanks.

  51. You had your chance. Developers and browser makers were listening. Now the browser makers have no one to listen to and it’s all up to them. In lieu of any guidance, the browsers are now independent. I sure wish MS would adopt webkit!

  52. Not a good move. HTML5 is the term in usage for the feature set among developers, the demarcation for understanding browser compatibility, and the marketing term. This is a huge step backwards for pushing HTML5 forward.

  53. Sorry, but this is a terrible decision. This will make feature comparison between browsers horrendous. Instead of a clean “check” for HTML 5, we’ll have to use a glut of table entries describing the various features instead. And don’t nobody go claim here that all browsers are on the same feature level because we all know that’s not the case. (and I’m not even talking about the 100s or 1000s of users *still* on IE6 for example)

  54. This is a terrible idea. Is it April Fools Day?

    Versioning gives people a reference point as to what’s new and what they need to learn. It’s why software has numbers on them:

    IOS 4, Windows 7, WordPress 3, Drupal 7

    How are you going to highlight new features of the HTML spec when it’s always HTML. Think of upcoming books on the shelf.. HTML. Some more HTML.. Got that HTML?

  55. I think very valid idea of the name back to HTML, because I believe that the W3C is a body that aims to standardize it, therefore defining what goes into it and not every new release it to give a name. Very good!

  56. I think very valid idea of the name back to HTML, because I believe that the W3C is a body that aims to standardize it, therefore defining what goes into it and not every new release it to give a name. Very good!

  57. If you don’t like HTML being a moving target, you’re going to hate the new kilogram. That’s right, if you’re in the habit of taking your 1 kg of deli cheese to the International Bureau of Weights and Measures to compare against the International Prototype Kilogram every week, you’ll need to get used to measuring it against physical constants.

    Even the best standards aren’t perfect representations of what you’re trying to measure. Here’s the proof: https://secure.wikimedia.org/wikipedia/en/wiki/File:Prototype_mass_drifts.jpg

    WHATWG has procedures in place to make sure that if you download today’s standard, you can code against it: future browsers will comply at least as well as today’s browsers. These days, if it’s in the standard, it’s battle-tested in at least a few browsers, and WHATWG knows people will rely on it.

    I’ve been writing HTML since 1993, and I have more respect for today’s spec– and the process that created it– than any previous one. I can code against HTML(5) more safely and reliably than any previous version. There has never been a time when I could just code to the spec without testing, but once something in the spec has been implemented by browser vendors and people start to rely on it, it doesn’t stop working.* This is a mature and time-tested process.

    *With the exception of bugs which get fixed really fast, and security issues that can only be fixed with a spec change. But these are exceptionally rare, and tend to effect very few websites.

  59. This is a great move. The W3C is becoming increasingly irrelevant (which is, of course, why WHATWG exists).

    For anyone that doesn’t understand, just check the doctype. It’s not .

  60. This is without a doubt the most retarded thing I have ever seen.

  61. Did W3C made that logo without consulting you? It sounds to me like a kind of revenge, but just about the anouncement time, the decision is OK to me.

    @Chris I think now books will be named like ‘HTML today!’.

    As WHATWG is conformed by browser vendors, I guess they agreed. And so, as long as I can use and LEARN what is new in HTML, it’s fine to me.

  62. Just what we needed. All hopes for all browsers supporting the same standard are gone, as there’s no standard but a moving target.
    That opens the floodgates for browser specific implementations, just as we were hoping that that’s a thing of the past.

  63. Are you serious???
    Versioned standards allow people to work with. One can say, this browser does that html5 standard to 99%. This decision makes building websites dirty hacking and browserforking forever. “living standard” means just that nobody has the balls to decide something. One inch has an exactly defined length, since long ago. Next big thing is a living standard for measuring. Ridiculous.

  64. Comparing a kilogram weight drifting to the HTML standard being a moving target is like comparing a needle to a haystack.

    The moving target that is HTML is huge in comparison.

    At least presently, what we have with the various existing standards is a target, and then you can code specifically for browsers you want to support that are off from that target. While some of the features that are “HTML5”, may not actually be “HTML”, having a consistent standard for the development experience is critical.

    Now, we are stuck at developing for a specific version of a browser, then trying it out on the umpteen other browsers out there and then adding specific support for each of them.

    In fact, while there are advantages to Chrome putting out a new version every 6 weeks or so, the downside is that it’s feature set then changes like that as well… As long as older features still work the same, we are good, but?

    Also how about support in browsers for previous versions of this “living” HTML standard? What feature set should IE X drop down to in order to be compatible with the HTML standard as of February 2011?

  65. Isn’t a wrong choice, in a fluid browsermarket-landscape that doesn’t depend on major releases anymore. The times, when several releases of one browser correspond with a static specification, are gone. We survived y2k and ie6 – nearly. Automatic updates are state of the art in the browser/engine market. As far as we all can look into the future there will be a bunch of apis on top of what now is known as “html.” – with a dot that connects this given standard with them instead of a number that seperates the now popular known – like audio/video – from them coming up in the next ten, twenty years. The only problem is the missing buzzword, but that’s not ours 😉

  66. So how is W3C’s “HTML5” and WHATWG’s “HTML” naming convention differences meant to fill me with confidence that the HTML … err… version 5 specification will be a coherent standard?

    Sounds like you’ve fallen at the first hurdle!

  67. This is a bad move. It’s hard enough to get people compliant with a standard when that standard is fixed and identifiable. Having just “HTML” mean any number of different things to any number of different people means that you will never have a fully compliant browser, and anyone expecting to use your spiffy new features is doomed to a support nightmare.

    Thank you ever so much for making it impossible to meet a standard that always changes.

    I guess I’ll go back to using b and i tags, because those at least have consistent meaning.

  68. LOL this means you will only able to add to a spec, not redefine it.
    Since documents will all have the same doctype a redefined spec will break things for sure.
    It doesn’t matter if all user update their browsers in a day for the redefined spec, all sites will have to be updated! That would take approx 10 years and waste energy. A DISASTER.

    You’ll need to introduce namespaces, versioned tags or revert to a pointer to a fixed specification soon.

    Unless this move is simply to facilitate the transition to a web with a handful of site monopolizing all traffic, just don’t call it WEB ’cause it ain’t one.

    EDIT: funny that in a whatwg blog I need to enable Javascript to POST A FORM

  69. Worst idea ever.

    How are developers to determine when certain parts of their pages will become invalid? Do you run through a validator that checks for compliance on a certain date/time? What about people who don’t want to be constantly updating their browser… certain parts of pages, or whole pages, will become invalid because on feature was changed a few weeks after the last release?

    Browser devs will be scrambling to keep up.

    This looks like a nightmare in the waiting.

  70. Worst. Idea. Ever. I really hope is a bunch of bull-honky and that someone only misunderstood something someone else said.

    Otherwise dissenting parties of the w3c would have to form a new group and create their own version of HTML. Then we would have two different competing versions of HTML, and nobody would use either of them, everyone would just stick with 4.01, except for Internet Explorer who would just continue to use their own. That’s not so bad, really. HTML 4.01 is just fine.

  71. This is a terrible idea. HTML5 was a standard that all browsers could work towards supporting and create the first universal web where people could choose browsers based on features and their personal preference, rather than if it supported a site they wanted to view.

    There is no such thing as a living standard – the worst phrase of 2011? A standard is something that is stable and that developers can validate web sites against. Imagine if C++ was a so-called living standard; each day would be different and your program might compile one day and not another. If this is going to be the case, the W3C and WHATWG might as well be disbanded as they exist to further the development of standards, of which the primary one, HTML has been dropped.

    I guess it should also be pointed out that the author works for Google – conflict of interest? I wonder how long before advert tags appear.

  73. So I guess, when writing a website, to ensure the most comprehensive and compatible use across any potential browser, I’ll just skip using any new features and go back to the tried and true way of explicitly defining, via “stable” tags that haven’t changed, broken, or been deprecated, tested against every version of web browser with a significant number of my users behind it.

    Oh wait, I do that already, because current browser companies do not, in any case, implement any revision of HTML standard in full. I guess you just wanted to feel better about that, since they can now implement, deprecate, or change whatever they need to as long as the specification containing those changes is current as of the time they release?

  74. Making things MORE ambiguous because your job is already hard doesn’t make things better. You’ve just confirmed that you are inept as a standards publisher.

  75. I was holding off on using HTML 5 on my website until it became a standard. Looks like it will never become a standard now. I can now keep using Strict HTML 4.01 with confidence.

    “Currently you have JavaScript disabled. In order to post comments, please make sure JavaScript and Cookies are enabled, and reload the page. Click here for instructions on how to enable JavaScript in your browser.” <– Booo!

  76. This is just official recognition that HTML has degenerated into a GFHM which only a
    few organizations have the resources to write verifiers, parsers, or renderers for.

    G=Godawful
    H=Hairball
    M=Mess

    XHTML, being simple and extensible in a uniform way, was supposed to make it possible
    for a wider variety of software developers to make a variety of apps that would work
    with marked up content, while remaining interoperable by complying fully with an
    easy-to-verify standard. But I guess that is just a tear in the great spaghetti monster’s
    eye at this point.

  77. How about feature-based document control, instead of nothing?

    Instead of the usual mess of “DOCTYPE html-version”, why not split the whole HTML world in to discrete, focused chunks, from media (img, video) to visual control (bold), formatting (tables, pre) to external content handlers(iframes, frames), and so on.
    So if i wanted to use Canvas, Audio and Video, i would specify something like <!DOCTYPE canvas, media> (obviously not that, simplified for explanation) They could even have version numbers for every major revision of each area (if needed, unlikely), so, canvas1, canvas2, or something like that. Basic, contextless containers will be parsed, regardless. (such as DIV and SPAN)

    Sounds awfully like another versioning method, but it is significantly more efficient on the client end since it only needs to parse content specified in the doctype header. If no doctype, it does what it always does without one, delicious HTML soup. (it doesn’t add any more complexity, outside of a few new tags, which are fairly simple anyway, besides canvas, audio and video)

    HTML has become too monolithic and the monolithic versioning methods are just stupid since barely anyone ever conforms to them. (even webkit) It is much better if we transition to feature-based versioning and feature control doctypes. Backwards compatibility can be handled in the usual way with doctypes, just hide the new information from older browsers, they (should) ignore it, new browsers ignore old information. It creates a much more solid method of targeting features in browsers, making it significantly easier to future proof your websites.

    Thoughts? I explained it pretty horribly, but here to answer any questions if you want anything cleared up.

  78. Yeah. The Javascript disabled error is incorrect. Both js and cookies are enabled.
    Oh, the irony of being prevented by a bug in html form processing code from commenting
    on lack of standards around HTML. Finally got through on third try with no settings changes.

  79. In the W3C HTML5 snapshot spec, there is a warning: “Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the aforementioned mailing lists and take part in the discussions.”

    Presumeably, with a “living spec” model, the HTML spec will never “reach the candidate recommendation stage”. Can the proponents of the “living spec” comment on the implications of this for software developers outside of the inner circle? When will it be safe to attempt to implement the spec based solely on the formal specification statements in the spec?

  80. How will anything be deprecated and removed if there are no version numbers? Will HTML become a bloated unimplementable mess as old features pile up, or will it become a dynamic unusable mess as features are removed and old valid documents suddenly become invalid?

  81. How can someone write this self-contradicting stuff:

    Instead of a clean “check” for HTML 5, we’ll have to use a glut of table entries describing the various features instead. And don’t nobody go claim here that all browsers are on the same feature level because we all know that’s not the case.

    If it’s not the case that all browsers are on the same feature level, what would a check for some version of HTML be good for?

    At maximum 1 browser would not fail, all others MUST fail, ‘cause they are on a different feature level. And guess what – there isn’t even 1 single browser conforming to any version of HTML.

    So versioning doesn’t help web developers. Feature detection does help them!

    Or how about this stuff:

    Versioned standards allow people to work with. One can say, this browser does that html5 standard to 99%.

    Eh? And which 99%? That 99% with the feature that would help your client or one of the 99%’s without that feature?

    Or how about this stuff:

    LOL this means you will only able to add to a spec, not redefine it. Since documents will all have the same doctype a redefined spec will break things for sure.

    Browsers don’t support a feature on a doctype basis. Doctypes for browsers are only relevant to quirksmode and such. One element might be “deprecated” or “obsolete”, but a browser will render it anyway. Try out the ancient plaintext element.

    Or how about this stuff:

    HTML5 was a standard that all browsers could work towards supporting and create the first universal web where people could choose browsers based on features and their personal preference, rather than if it supported a site they wanted to view.

    Versioning doesn’t magicaly make all browser vendors equal in terms of feature implementation success. You might not yet have understood that the WHATWG spec is the browser vendor spec. Regardless of naming it HTML, HTML5 or TTFHGZD4U2TS99AEXFCGFZ. Look at the copyright note at the beginnig of the spec.

  82. This is an absolutely terrible idea. I don’t know how anyone could possibly support this. I guess I’ll be writing all my pages in HTML 4.01 from now on, as well. Just unbelievable.

  83. Cool. So then we won’t see snapshots (aka “non-moving-targets”) from WHATWG. We’ll only see snapshots from W3C. This removes any uncertainty about where I should be looking for specs to develop to. I’m sure WHATWG will continue to provide a valuable service in evolving the standard, and will influence the specs published by W3C. But when I want to read a spec for the purpose of developing something, I now know where to go: W3C.

  84. You guys had a hard job–make a standard out of a chaos of neverending requirements. I don’t think you were up to it. And now, you think redefining the problem to not exist will make a neat solution. It doesn’t work that way. You’ve merely passed the problem on to all the developers, project managers, and other IT workers that have to make software that works. You inflated the requirement gathering, design. Implementation, testing, and validation portions of 10,000 software development projects, all because you didn’t have enough persistence and practicality to say here is a known thing which we will give a single name. That is your job when you sit down to right a standard. If you can’t do it, get out of the way and let somebody else do it. Don’t sentence the IT world to ambiguities.

  85. This proposal seems to be based on the (true) observation that HTML in practice continually evolves, and browsers continually evolve — and then draws from that the (false) conclusion that defining fixed coding versions is therefore misleading or archaic.

    What this proposal forgets (or doesn’t care about) is that our history, our historical records, and our legacy are being written on the Web now, not so much on paper any more. The text part of the content may always be readable, but formatting is not just “decoration”, it’s part of the meaning. Nobody is going to go back and continually update/refactor the code on all the existing Web pages. Sure, their old doctypes will still be in their code… but will future “no doctype” browsers have any idea what they mean? Will the browser developers even bother to maintain backward compatibility in a “no versions” world? I’m concerned that this “no version numbers” idea is obsessed with process and with the future, and ignores the present and the past, which are important to.

    Not to mention that this is the biggest wormhole to enable any irresponsible browser makers who might wish to avoid or subvert any meaningful meaning of “standards”.

  86. So you will never be able to check that a html document is well formed in the future, because there is no single specification to check against? If there is no fix standard to check against? Since the default character encoding has changed (and will perhaps change again) all encodings are correct?

    You’ll never be able to remove or deprecate elements. Once “font” is in there, it’s always correct. Or will you try to say “Valid html according to 2012-05-24 01:05:05 UTC” (but no guarantess before or after that). Good luck with that.

    Web browsers will never be able to boast “full support for html/css3”. This will not help the web.

  87. Is this really such a good idea?

    Please respect the following points:

    1. With this move, WHATWG claims responsibility for HTML as a whole. As a W3C member I could by very, very angrily about that! HTML is not just HTML5! This move blatantly ignores and busts HTML’s history.

    2. By making HTML(5) a “living standard”, the policy-making nature of the standards group’s output is watered down – a standard may be a “formal document that establishes uniform engineering or technical criteria, methods, processes and practices”, but for the versatile, democratically administered web the (W3C) standards (or “specifications”) always were much more than that: policy-making, guiding and trend-setting! They coordinated all the input and created proposals that were applicable to more than just two or three (browser-)vendors!

    This decision will (IMHO) degrade the “HTML standard” to a plain changelog of HTML history as it is implemented in web browsers at its time. It sounds just like a formal process collapsed, and probably it saw its own deficiency and just gave up!? Because WHATWG could not coordinate it at all? Sad!? But if thats the case, then WHATWG should just vanish silently and leave the field to W3C.

    In other words: WHATWG will become a pure historian of HTML development! It will loose the role of a guiding standards publishing group.

    I just hope, that the W3C will take over HTML(5). Even if it is a little bit slow. But WHATWG just demolished itself.

    WHATWG temporarily had a good reason to exist, but that seems to be gone now.

  88. @Ian Hickson: The FAQ states that “Maintenance means that the days where the specifications are brought down from the mountain and remain forever locked, even if it turns out that all the browsers do something else, or even if it turns out that the specification left some detail out and the browsers all disagree on how to implement it, are gone.”

    Sounds good, but HOW will that be realized? I mean, the statement in itself sounds great, really good and great, but what are the practical implications? What is your plan to ensure that this statement will hold true?

    Somehow, I don’t see that moving to a “living standard” helps here that much!

    It may sound like a good idea, but it does not solve actual problems. Right?

  89. Seems to me that WHATWG was frustrated by the W3C standards process and simply decided to opt out.

    Version numbers make it possible to refer to the standard at a particular point in time. Browsers can currently say they implement HTML 4.01 and most know what to expect. In future it will be “HTML 2011-01-19” or similar in an attempt to express the features supported without resorting to listing them or requiring feature testing from the ground up.

    An ever changing, unversioned “standard” is useless.

  90. Lets be practical,

    Why would I use <section>, or <article> combined with <div>, when I can use just <div>s? There’s no longer a spec.

    Why use JS for compatibility? Why make websites for the future?

    People have spent hard hours improving the transition situation of HTML5 in non supported browsers. Not to mention building up the brand which is a whole new movement and a part of “HISTORY”.

    Ian

    This is not helping right now people are no longer going to design future proof websites. It’s not a name it’s a specification you’re toying with and it’s not one developers project it’s millions of dollars you’re shifting around due to WHATWG’s indecisive, insecure child like ambitions.

    It seems like there’s some hidden agenda, I mean this is like a political move right after Google announced no support of H.264!!!!!

    My suggestion is to give people what they want.

  91. How does this help a web programmer on the ground? Right now, if a browser says it supports HTML 4.01, I can go look at what that means.

    If my browser supports HTML, could I go to your spec and read about what that means for a particular element quickly? Or would I have to search through the version control of the living document to reference the particular implementation that a user might have (my users definitely won’t have the latest nightly build). I don’t think it makes sense for each developer to have to read the entire history of an element to make sure I’m addressing the browsers out there that have implemented a particular version of the new “HTML”.

    This will just create headaches, and I’m not sure what the benefit of having a “living” standard is to anyone but the standard creators’ convenience? While there is no standard now since it is constantly being fleshed out, and wouldn’t be published for-practically-ever, doing away with markers without a detailed explanation of how this benefits the web AND its developers strikes me as an amazing act of hubris.

  92. Mr. Hickson (and other WHATWG members),

    Others have already pointed out several drawbacks to this decision, including the inability of browser makers, web developers, and web designers to know what version of the HTML5 specification they’re supposed to use. I’d like to offer a possible solution to the problem: Adopt the “module based format” used by CSS3.

    This would allow you to separate HTML5 into it’s component technologies and focus on each as an individual unit.

    Note: I haven’t actually looked at your spec in a while, and you may be doing so already.

    But please consider reversing this decision. You signed up for the job of making HTML5; If you can’t do it that’s fine, but this decision just forces your work onto the rest of us.

    Thanks for your time.

  93. Come on, be serious! Nobody at WHATWG knew that W3C would come up with a logo (incl. Merchandising)? Nobody could have warned them? I have no problem with the renaming itself, but -by intention or not- the timing is the fail of the year.

  94. The entire community of web designers committed to using XHTML1 now and forever thank you.

  95. Sounds a bit silly really.

    How do you even describe then what is supported by an implementation and what isn’t? By listing features? I think not.

    People will start using document dates as version numbers instead.

  96. @Lyle – Browser vendors saying they support x.y version of html is usually a guessing game anyway, as they seem to have a different interpretation of the word “support” (some more than others). You have needed to check individual browser implementations of different parts of any standard for a while now, this is nothing new and was unlikely to change under the HTML5 banner.

    I like that this clarifies what html within html5 actually is, people can/will keep using the term html5 for the superset of technologies it has come to represent.

  99. I’ve tried to provide answers for most of the points above on the FAQ: http://wiki.whatwg.org/wiki/FAQ

    I hope that helps explain the decision.

    Most of the comments seem to be based on the misconception that browsers target a particular version of the spec, possibly even targeting one version before moving on to the next. That’s not the case. Browsers always follow the latest draft, because that’s where all the bugs have been fixed. They do this whether we call it an Editor’s Draft or (more accurately) a Living Standard. As far as browser vendors are concerned, this recent announcement really changes absolutely nothing.

  101. Without pointing fingers, the politics around this stinks.
    Nonetheless, it feels like the right move at the right time. Spec writing in the Git generation. Could it smooth acceptance to use related terminology such as trunk and merge ?

  102. The day HTML died. Sounds like a Linux way of doing things… 50 million distributions, good luck trying to write software for them all.

  103. @John N

    > Browser vendors saying they support x.y version of html is usually a guessing game anyway,
    > as they seem to have a different interpretation of the word “support” (some more than others).
    > You have needed to check individual browser implementations of different parts of any standard
    > for a while now, this is nothing new and was unlikely to change under the HTML5 banner.

    True enough. But that’s been the nightmare process for developers for years. The movement to standards-based coding has improved immensely in recent years – and I attribute that to the increasing pressure on vendors to “fully” implement standards, CSS2.1 for instance. That was a great milestone that vendors could reach (or fail to reach and be derided for). That type of pressure was one of the reasons IE finally changed their broken box model.

    It’s disingenuous at best to say that developers currently have to look at everything across all browsers anyway. The average web developer on the ground has limited time for that – and in most cases doesn’t need to. For instance, a developer now can code to a set of standards that they know are widely supported: CSS 2.1 and XHTML 1.0 Transitional for instance. While most realize that some browsers don’t support things in those specs (run-in, etc.) or have bugs, it gives them a point of reference for what they can and can’t use. They don’t care about the tiny differences in the implementations typically, because they are minor enough compared to the fact that they know they can use nearly all css2.1 selectors, and that they will work across the browsers they need to support.

    I and many other developers need that reference/crutch in order to be productive. Living standards that change over 5-10 years will result in even more browser inconsistencies as they are constantly implementing and releasing changes to match the changing spec. Some will release features at different times and that will continue to affect developers years after a decision. While that might be fine and dandy for the spec makers and those on the cutting edge that want new features now, that’s not the majority.

    Those using “Can I Use” on a regular basis are a small subset of the population. They are your current base and I understand designing for them. They are the experimenters, etc. However, the real base, the majority of developers, wait a long time to make sure there is extensive cross-browser support before implementing something. I only look at “Can I Use” when I want to use something I’ve heard about, and if it isn’t green across most of the top – the answer is no.

    > I like that this clarifies what html within html5 actually is, people can/will keep using
    > the term html5 for the superset of technologies it has come to represent.

    I don’t care what you call it. I care about being able to say that a subset of the standard is supported. If that’s HTML5betaA1, whatever. Removing milestones that can be referenced as mostly supported (who cares about ‘fully’ unless it’s a feature you really want to use) will just make my life harder, and many more like me.

    I understand why the decision was made. The logic behind not having standards that are known to be wrong, etc. However, removing versioning doesn’t help the vendors develop targets to reach first. Each one can instead decide to focus on whatever interests it at the time. That will lead to even more drift between what is supported.

    Change its name, call it a living standard, whatever. But give the developers (and vendors) some targets. Whether those are minor milestones such as supports “HTMLbaseElementSetad9034” or some suite of increasingly complicated test suites, then that would be enough to satisfy me.

    Giving vendors some idea of relative priority, and developers some idea of those priorities, will help us understand what’s coming, and what we can hope to actually use in the massive forever-pending spec.

  104. I think it’s potentially a superb idea to drop versioning for the language. The advantage? It allows ease-in of new features without adoption of an entire new language version, which is bound to be more acceptable to browser vendors. (Easier to sneak in a “figure” tag, and have it gradually accepted, than to sneak in a broad swath called “HTML5”.)

  105. So will W3 continue to use version numbers periodically to refer to snapshots of the WHATWG “living standard”? How about a follow-up post to clarify this confusing nonsense?

  106. So, guessing yearly rolling standards would be the new norm?

    i.e.: Future validator tests reading something like — this page is compatible with HTML 2012 Strict, HTML 2015 Transitional, HTML 2017 ECP Draft A?

  107. “Most of the comments seem to be based on the misconception that browsers target a particular version of the spec, possibly even targeting one version before moving on to the next. That’s not the case. Browsers always follow the latest draft, because that’s where all the bugs have been fixed.”

    Do you speak for all browser vendors?

    Anyway, fixing bugs is one thing; experimenting with new features is something completely different.

  108. I see, and we’ll put little banners on our websites that say “Best viewed in IE9.1” so people can guess which tags and features we’ve used?

  109. EPIC FAIL.

    HTML5 is not “HTML”, it is HTML5, the fifth version of HTML. In fact the moment I saw the versionless doctype years ago I vowed never to use it. I’ll use XHTML 1.1 to extend support for HTML5 features in the future should the need arise.

    So we should call CSS3 “CSS” now? Well that means that whatever the most CSS 2.1 compliant browser that doesn’t support all of CSS3 only has “partial CSS support”.

    Calling HTML5 “HTML” suggests that HTML 1~4 did not exist or have been outright replaced. The potential for marketing related lies and stupidity is mind bending. A browser that support say half of HTML5 could be called by non-technical writers who call elements “tags” could say “Browser A only has partial HTML support” which could be used as outright slander.

    Imagine trying to reference a chapter in a thousand page book, though none of the chapters have numbers or names…how the heck are you going to reference a specific chapter? …and any replying fool who suggests a page number is taking it too far out of context.

    The fact that this was even given any serious consideration speaks poorly of whoever suggested it in the first place. The fact that this made it to the public speaks massive amounts of fail on behalf of WHATWG. Stick to working on the standards and knock off this stupid marketing crap.

  110. I think this change makes sense. This way you remove a little bit the hype behind the changes. Good decision IMHO!

  111. @John CSS support has only been partial for years, nothing new there as of yet.

    This move is fantastic, as i just stated on the mailing list. Exactly the kind of thinking which will keep things rolling in the future. It might even invite otherwise hesitate web designers, to adapt new elements.

  112. The problem is u should of been calling html5, web 2.0 standards family and html5 is just html version 5. i think want ian is pointing out is that this the doctype most revised version being reset to html and not adding html5 but html5 should be defining what works with that for web developers. Browser implementers dont care about it becuase its always adding and changing but everyone else needs i. How is any developer suppose to buy a book about html if there is no reference but a document that is only current. software is not like gmail and always beta. sure versioning creates tons of problems. This is why doctypes suck but the world operates this way unlike Google. There is suck things as internal codename. and external standards. And for u too not keep the two seperate is a big fail and to not understand how the world operates. 90 percent of anything that is manufactured is created based published standards. And failure to give it a proper version for the public is downright
    Stupidity at its finest. If no one had to reference if software works with which standard i would say your right to de reference html. But to say html5 is html is fine but not also html5 is the latest version of html and what everyone refers to as html5 should be called web2.0

  113. I had a lot of troubled trying to type that on an andriod2.1 keyboard. Hopefully google will make one i can use arrow keys to move around on. I see this whole mess as a failure in. Arketjng. Html5 is html to your brower and were working on ratifying the lastest and greatest as a full web2.0 family of tech standards which include html revision5.

  116. Did you know “living standard” is a contradictio in terminis? And with calling html5 just html they just lost my trust. Actually not having a proper doctype in html5 already blew my mind. Where is the W3C?

  117. Good move. Snapshot model is so yesterday. Standards related works should really follow iterative unversioned model where applicable because tech companies have been dealing with and implementing standards in this way intrinsically.

  118. A fundamental user requirement is confidence in the integrity of the applications and the data that they depend on. Related needs are consistency in processing logic and user interface, and communication of changes to them, preferably in advance, with access provided to documentation that enables them to think through the ramifications of the changes.

    During the last two decades, developers have become slovenly to the point of recklessness. The abandonment of the design phase ensured speedier delivery, but also error-prone and ill-fitting applications. The abandonment of data models and data dictionaries led to lack of clarity about what data means, and hence rubbery semantics. The abandonment of supplier-provided documentation resulted in uncertainties about what applications do and how they’re meant to be used.

    The abandonment of versioning, justified by the spiffy-sounding term RAD, meant that features may or may not be present, and instability is assured.

    Now we’re reached the point that a standard-setting organisation has destroyed the integrity of their standards, using the justification that integrity, reliability and stability aren’t respected by anyone else, so why should *we* bother ourselves with it.

  119. For lack of eloquence, this is the dumbest thing I’ve seen come out of the WHATWG thus far.

    Fortunately, the W3C is the governing body here, and this foolish nonsense should be enough for the W3C to remind everyone of that.

  121. ???????“html5”?????????????????????????????html??html????html??????????????????????????????????????????????html?html5????html5??ajax???????????????????????????????????????????????????

    ps:
    whatwg????w3c??html5 logo???????????

  122. @Tom
    “Not a good move. HTML5 is the term in usage for the feature set among developers, the demarcation for understanding browser compatibility, and the marketing term. This is a huge step backwards for pushing HTML5 forward.”

    i agree with you

  123. A little more than a century ago, every town, city and province, state or region in the world used a system of local time for setting clocks, and it seemed to make sense. Noon was when the sun stood directly overhead, so noon in New York City would occur a few minutes earlier than noon in Pittsburgh. But developments in transportation technology, like transcontinental railroads, soon made people realize that such a system was terribly inefficient and inconvenient, forcing people like train conductors to carry sometimes a dozen or more different watches, each labelled with a different city and set to its own version of time. Sure, it “worked”, but it was really hard to make it work, and there were a lot of “times” (sorry about the pun) when it didn’t.

    The solution was to come up with a STANDARD. It was first proposed by a Canadian engineer named Sanford Fleming, but it was resisted for years. But finally the sense was realized of having a “standard” that everyone in the world could use as a common reference point for setting clocks and making schedules. A “prime meridian” was chosen and on January 1, 1885, at the International Prime Meridian Conference in Washington, the world formally adopted Fleming’s suggestion of 24 zones of Standard Time, each one hour apart, that we have used ever since.

    Standards are not just about marketing. They are not about fads or fashions. Standards are critical to concepts like dependability, efficiency, productivity, effectiveness. Standards counter chaos. And to have a standard, you must have some kind of fixed point of reference — a Prime Meridian.

    That doesn’t mean that standards can’t be improved upon. Maybe someone will come up with a better idea for organizing time on the earth. But there will need to be a common agreement to that better idea — an agreement on a new point of reference — or there will be chaos again. The term “living standard” means . . . very little of practical use.

    Standards bodies need to exist. And they need to do their job by saying: this is the point of reference against which you measure where you are and where you are going. In the case of the practice of web development, surely there needs to be a standard that is more than just “local”, more than just “what a few of the browser makers want to call HTML today”.

    Put the number back on HTML! Let there be a point of reference to compare against, to shoot for. It may have taken years for the world to agree on a standard way of doing time, but agreement did come, and it was worth it in the end.

  124. That’s completely ridiculous, we need a simple, light and stable spec, not a bad written evolving draft as the WHATWG is trying to do. Please stop this insanity and join W3C. We can’t have two HTML specs that’s pretty stupid.

  125. @AJ King

    Great Western Railway in Great Britain adopted Standard Time in 1840, but I get your point.

    This is a ridiculously bad idea, and has sapped any interest I had in HTML5 away. There is no way I’m going to be supporting this travesty without some kind of version system.

    I’ll stay on XHTML for now, thanks. At least there I have a shot at consistency.

  126. ????? ????????? ????“IE6??HTML”? ??????????????HTML???????lol. ??????????????????????

  128. HTML is too simple. I was proud of HTML5 before. Using HTML is hard to google and find the book with new features of HTML.

  130. @AJ King ,
    the problem is the standard you are talking about didnt evolve much , whereas the web is evolving fast and standards become swiftly obsolete. HTML5 is already obsolete , we need to get read of the 5. It doesnt make sense.

  131. This seems like a very very immature decision for a standards body to make. How intimidating is that to a developer that would rather actually work than spend each day trying to keep up with a standard as stable as a nightly unchecked cvs build. No, there might not be perfect unison when it comes to present day browser support of a single standard, but there is at least an effort made towards that. This will lead to even greater fragmentation of feature support than we experience in current days. Please reconsider this; two wrongs do not make a right.

    -C

  132. The only way this can work is if WHATWG’s document is a living *specification*, not a standard. It should still have drafts and versions so that developers can refer to it at a particular point in time (e.g. if I’m told feature x was updated in version n.n.3 and I’ve been using n.n.2, if feature x is important to me I need to check the newer version).

    Then, from time to time, a *standard* can be released that is those features that have been consistently implemented by the majority of browser vendors. This is essentially how the HTML 4 and DOM standards developed.

    It will allow the specification to lead development and provide a roadmap for the bleeding edge (like a functional spec does in traditional development) while the standard provides the backup, normalised version of what has been implemented (essentially an as-built to provide a baseline).

  133. This is absolutely the right decision. To make it clear to everyone who commented without checking first, the W3C *will* still be publishing a version-numbered standard – there are no plans to change their model, and even if there were, change does not happen quickly at the W3C (not a jibe or a criticism, just an observation). The WHATWG is going to be focused on developing HTML. Their work won’t be based on producing a final, finished standard. HTML will constantly evolve. This is good.

    Nothing will prevent the W3C from publishing a “HTML6” standard at any point in time. Marketers and journalists would be free to use it as a buzzword as they have with HTML5. Users would have a reason to upgrade their browser so they can “enjoy the benefits of cutting-edge HTML6 technology”. As Hixie pointed out, browser vendors don’t work to version numbers, they work to features. This is why mature standards aren’t consistently implemented to the letter across all browsers even when they’ve been around for years.

    That leaves web developers. Like browser vendors, developers can and should work to features and not to version numbers. If you want to use a feature e.g. datalist or canvas, you should be asking questions like “where are the browser implementations at?” and “how backwards-compatible is it?”. If you are asking “is the entire HTML5 spec finished?” then you are missing the point.

    Incidentally, if you really must validate your document against a version of HTML, then you’ll probably still be able to for the foreseeable future, because the W3C will still publish “HTML5” and “HTML6” and you can choose which version number to check against when you run the validator. The actual content of the DOCTYPE is unnecessary. As far as I know, the only reason it was left in at all was because it is required to trigger standards mode in some browsers.

    @RobG #132 I agree, it should be “living specification” not “living standard”. To be honest, I think that’s what is meant by it, it’s just slightly faulty terminology.

  134. Great move:

    1. It just makes peace with the reality of HTML implementations. No one implements “versions”. Instead, particular elements get implemented (or not).
    2. Removing elements that turned out not to be so great will not be a problem anymore. It is hard to remove something from an “established” spec. Usually one needs to wait for the next version. Now it is only a matter of mutual agreement and implementation. No need to wait for other parts of the new version of the standard to be finished.
    3. A distributed, constantly negotiated standard? Matches the nature of the Internet perfectly. Seems kind of cool as a concept, too.

    No pain, only gains.

  135. This is a costly development for web authors. The only thing that makes it potentially viable for other stakeholders is that it is the product of agreement among a cabal of major browser implementers. If they do what they say they are going to do, curate HTML, in a logical, popular way, their definition of HTML will at least have some internal consistency, at the cost of the standard’s and the real standard body’s legitimacy. But web authors will be left poorer and more befuddled than before.

    WHATWG’s approach is weaker than W3C’s because it destroys value. W3C was adding value with the version number, since it stood for what is new and interesting and commanded attention at a ripe time. Ironically, the WHATWG’s new moniker “HTML” is never changing. Stagnant. Stuck.

  136. @AJ King, @Chris

    Just for the record, Sanford Fleming was Scottish and moved to Canada in 1845, so would have known about standard time for 5 years before moving to North America.

  137. Not the best move, IMO, I am surprised. Perhaps evolutionary development model makes sense – I have no problem with that, but any evolution (take as example history, art, science, technology) always has been a subject to classification, taxonomy and categorization.

    Taxonomy and classification create points of reference essential for communication, media, education, research, business, etc. In the current dynamic world a technology such as HTML can and must have points of reference, categorization, versioning, standardization and branding.

    Branding is the most important vehicle to promote new technology. HTML5 actually became great sexy brand thanks to WHATWG. Why destroy it? The W3C just came out with pretty cool HTML5 branding, logos etc. the first time in 20 years: good job, though is it very bad that the branding move was not coordinated between both bodies.

    On the other hand, the term “html” used as substitution for HTML5 is too generic, vague, boring, misleading, stagnant, and dated. Why don’t we retain the HTML5 term and brand, declare it living standard, continue evolutionary development while releasing subversions similar to Mac OS 10.5 Tiger, Android 2.2 Froyo, or HTML5.1 Nika.

  138. I believed lynx supported HTML 4.10 but it appears that it sadly no more supports HTML
    When will DOC and ODF become “living standard” ?

    Aren’t API and version numbering a *must* for free software, libraries reuse and Unix philosophy ??

    I take a simple example: REST in HTML forms
    http://www.w3.org/Bugs/Public/show_bug.cgi?id=10671
    [ note how the URL is now wrong as the Drafts itself evolved 🙂 ]
    The last comment mostly says: “wait later”
    What will happen if it is considered in the future ?
    Also note how the javascript-way-to-do is considered as sufficient (don’t we talk about HTML there ?)

  140. #29 thebuccaneersden said: “The web really is a living document, so we might as well just call it “stuff on the web” instead of HTML.”

    I think you mean SOW.

  141. This might make sense to the people on the working group, but as someone who actually tries to work with the output of the W3C this is a pain the arse. Whether HTML5 is actually the ultimate and everlasting version of HTML or not, we need to be able to refer to it separately from previous specifications. It doesn’t matter if it’s theoretically unnecessary, it’s a practicality.

    This whole “no version necessary” thing is theoretical purity overruling reality, in contravention of your own stated principles. So the doctype doesn’t need a version? People would have felt more comfortable if it did. So the specification doesn’t need a number? People could at least refer to it without confusion. It would have helped us implement The Spec Formerly Known As HTML5.

    With no clear end point, no date when you say “this version is done”, out in the real world we have IT managers demanding to know why the hell you’d implement an unfinished technology. When do you schedule it? When do you spend the budget? Other technologies have numbers…

    “Living documents” do not help us champion standards one little bit. Stick a number on it and when you’re done, start working on HTML5.1 or 6. Label the versions according to when the modules in them are finalised – after all if you change the modules later, then we don’t have any standards or stability at all; we just have permanent browser wars.

    Give the world milestones, it’s how IT works. You can chuckle at how silly it all is but that’s the reality.

  142. Someone pointed out that I said W3C where I should have said WHATWG. The fact we have to do that kind of doublethink doesn’t help. Same comments apply, amend to say “output of the WHATWG”. All good? Cheers.

  143. Before this decision we all hoped to be able to build products compliant with HTML5 and get rid of the old system where we agreed with the client which specific browsers (and browser version numbers) the product should work with.

    WHATWG now crushed this hope. We are back to square one and specific browser builds will be the reference used in specifications and contracts.

    This is good for the browser vendors in a way. No one will hold them responsible for their bugs. Their bugs will continue to the part of the reference upon which the web is built. Just as it has been.

    Me? I am moving further into writing iOS apps – I dont have time for all this politics, I have some nice new product ideas to try out.

  145. So, I’m a big company and I want to commission a web site. I want it to work well in lots of browsers. Traditionally, I specify in the contract that it must conform to standards X, Y, and Z at versions i, j, and k. When the supplier delivers it, I can measure whether they’ve done what I asked for, and pay them accordingly. It might not guarantee that the site actually works properly on every browser, but at least there’s no dispute between me and my supplier.

    What am I supposed to do now?

    This proposal seems to forget what standards are for. Standards are contracts.

  146. Sorry but for me a “living standard” is “no standard” at all. I was starting to get used to work with products and libraries in beta phase (no matter if iopensource or not) but make the industry works with “beta standards” it’s too risky imho.

  147. Does HTML work with the internet explorer from Mozilla so I can surf the facebooks and google for youtubes?

  148. I prefer to take a pragmatic approach to this. If the 5 is used to denote properties that distinguish HTML5 from other forms of HTML, as these differences are important for developers, then I would like to see some form of version included. I understand what you are trying to get away from as I had the same issues with SOA and Web Services when I participated in standards development.

    For a developer and architect however, even with the backwards and forwards compatibility and RFC 2119 keywords worked into the specification, they still have a requirement to potentially distinguish both the markup and feature set from a more generic HTML moniker.

    I would invite an open discussion on this topic.

    Duane

  149. The comment form on this blog is not even a real HTML5 form.
    ( eg. it doesn’t use input type = email )

    Ain’t that funny ?

    A lot of developers talk ( tweet / post ) about the coolness of HTML5 while their very own blogs don’t even implement what they tell or suggest people to do.

  152. Seriously? I’ve been going around for two years calling it HTML5 and now they’re calling it just HTML? Really?

    From a technical standpoint, this is a bad move as future versions of just HTML may be incompatible with what we’ve got now (which I refuse to stop calling HTML5 under any circumstances) in the event that any features are deprecated and subsequently removed from the specification. You will really need to be careful.

    From a marketing standpoint, this is a bad move as HTML5 has been a buzzword for… erm, a very long time.

    What happens when “HTML6” comes out? How are we going to differentiate it from HTML5 without a version number? I propose that a version attribute be added to the <!DOCTYPE html> declaration. Specifically, the value would be version="4.0", version="5.0", version="6.0", etc.