By Craig Buckler

HTML5 is Dead. Long Live HTML.

By Craig Buckler

The Web Hypertext Applications Technology Working Group (WHATWG) — the organization which instigated HTML5 — has announced they are dropping version numbers. HTML5 is complete. The new standard is simply “HTML.”

The announcement was made by specification editor Ian Hickson. His blog post states that the HTML standard has become a living document:

  1. The specification will be known as “HTML” with the URL
  2. The WHATWG HTML specification can now be considered a “living standard.” It’s more mature than any version of the HTML specification to date, so it makes little sense to refer to it as a “draft.” The snapshot model of specification development has been abandoned.

What About the W3C?

The WHATWG announcement came two days after the W3C launched their HTML5 logo.

The term “HTML5” is unlikely to disappear since the W3C standards approval process is structured around a progression of version-numbered technology specifications. Currently, the W3C remains committed to HTML5 and they won’t necessarily follow WHATWG’s lead.

However, the new logo has muddied the waters, and the W3C appears to be lumping CSS3, SVG and JavaScript APIs under the HTML5 “brand.” Although they’ve backtracked a little on their logo FAQ, it’s becoming increasingly difficult to refer to HTML5 as a specific technology when its own standards body has jumped on the marketing bandwagon.

Do We Need Version Numbers?

Many developers expressed their surprise and horror at the WHATWG’s notion. IT revolves around versioning. Development will descend in chaos without those digits. How will we know when a browser reaches compliance? How can we test code against a specific version of HTML?

Don’t panic. Dropping version numbers may feel unnatural, but web development always has and always will be based around a disparate set of ambiguous technologies.

There’s a widespread misconception that the W3C writes specifications for vendors to follow. This leads many developers to the conclusion that HTML5 won’t be ready while those documents are labeled “draft.” In reality, browsers are continually updated. HTML features are added and, if they’re considered good enough, they’re shared with or copied by other vendors. It will only be documented in the specification once two or more vendors have implemented the same feature. In the majority of cases, a feature will be usable before it’s documented.

HTML version numbers contribute to the confusion. It feels wrong to write code based on a “draft” HTML v5.0 specification. But consider this: XHTML 1.0 is “final,” yet it won’t be supported in Internet Explorer until version 9. Similarly, CSS2.1 is complete, yet no browser offers a full bug-free implementation. Finally, if you’re using stable CSS3 features such as rounded corners, why is HTML(5) any different?

Today, all the browser vendors claim HTML5 compatibility. However, it’s to wildly differing levels and no one supports everything. There are numerous browsers on desktop, tablet, mobile, gaming and other platforms. Each has a different set of features and evolves along its own path. You’re free to wait for the magical day when the specifications are complete and have been fully implemented by all vendors, but you’ll be waiting a long time. Even when that day arrives, browsers will have moved to the next technological level.

It’s controversial, but I agree with the WHATWG. All-encompassing version-numbered specifications have become too large and unwieldy to be practical. Fortunately:

  • No vendor has a browser monopoly nor can they (easily) sway standards in their own direction.
  • The main browser vendors are working with each other. They are innovating individually but must share ideas with others to ensure a feature becomes an accepted standard.
  • HTML evolution is (mostly) backward compatible. For example, all browsers accept the new <input type="email"> tag but older editions will revert to <input type="text">.
  • Vendors rarely remove technologies from their browsers. Google is ripping H.264 video support from Chrome but, in general, HTML code will remain operable in the browsers in which it originally worked.
  • We’ll always require feature detection. You can never depend on the availability of every HTML tag, CSS, JavaScript, SVG, Canvas, Flash or any other technology. Where necessary, you can detect its presence and provide alternative content. That situation won’t change — even when the HTML5 specification is complete.

A living HTML specification reflects the current state of web technologies today.

Do you agree? Will it work? Comments welcome…

  • ana

    right now I’m happy with just HTML, haven’t tried HTML 5 yet, don’t even know the difference lol

  • Absolutely agree with you. There is no need for numbers in HTML anymore, we can work with feature detection… as we’re already doing now. No big deal, then! Just a nice little touch that had to be done.

  • moneymark

    This has to be the most asinine move yet. I can only assume the people agreeing that this is a good idea are web designers and not software engineers. The HTML specs are plagued sadly by classic feature creep taken to the 20 year extreme. If we could simply define what should be supported by 5, we could move on and place the remaining draft candidates into a v6. Otherwise we risk diving back into the dark ages of browser detection and IE workarounds. Define a spec, adhere to it, evolve.

    • The HTML5 specifications are not the same as standard software specifications. There’s a fundamental difference: when creating software, you write a specification first. HTML becomes a standard after the software is written. In other words, the document is a historical record of what’s been implemented (although not necessarily in all browsers).

      • Alex

        You’re right, but the problem is that this is ass backwards. Maybe server vendors should all start supporting “cool new” HTTP features every year and we should make HTTP a living standard too. Then the browser developers will see what it’s like not to have a steady spec to work with.

        As to the number 5 itself, who cares. But the feature cutoff does matter, if only because when lots of web developers use a certain set of features, the browser developers must focus most of their efforts on those same predictable features, not constantly think up their own new ones that can vary in their implementation. If web developers give up the feature cutoff, they give up whatever tiny bit of control they have over the browser vendors.


    Good point. Who cares what version it is? So far, there isn’t a lot within HTML5 that I couldn’t already do in different ways. It did make a few things easier though. Now CSS3 looks pretty cool to me. Come on Internet Explorer, holding up progress for the rest of the world here!

  • Anonymous

    It looks like another excuse for the browser makers to me. Sure, some will be ahead, on top, trying to fit all the latest stuff in. But as we’re all aware, some are lazier than others when it comes to implementing new things and removing the versioning gives them just the excuse they need. So yup in an ideal world this would be a great idea, but as things stand I don’t see it working. The web will regress.

  • aking10

    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 was directly overhead, more or less, so it would be noon in New York City a few minutes earlier than noon in Buffalo (in the same state). Local authorities decided what their clocks would say the time was.

    But developments in transportation technology, like railroads, soon made people realize that such a system was brutally inefficient and inconvenient, forcing people like train conductors to carry sometimes a dozen different watches, each labelled with a different city and set to its own local version of time. Scheduling was a nightmare (something like doing a different web design for six different browsers). It would work, 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. A global solution 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 fixed 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.

    Provinces, states or countries may choose to differ from Standard Time, but when they do, it is known, it is consistent, it is predictable. It can be worked with. Efficiency and sanity do not suffer.

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

    It 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 . . . What? The fog of confusion. 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. There is a standard that defines C++. That defines ANSI codes and UTF. In the case of the practice of web development, surely there needs to be a standard for defining HTML that says what it is and what it isn’t, that is more than just “local”, more than just what a few of the browser makers want to call HTML today. Developers need predictability and dependability for their code. We need specifications that mean something.

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

    • There’s no reason why a point of reference can’t be added, e.g. this is HTML 2012 or whatever. What’s the benefit though? It won’t change what HTML features a browser does or doesn’t support.

      • aking10

        Adding points of reference to the development history of any standard never guarantees what features of the standard will or will not be supported. But the point of reference gives consumers of that standard a way to know which features to expect or not expect from both conforming and non-conforming platforms, and thus to make informed choices about the platforms they wish to use.

        Take away a fixed point of reference and you just add immensely to uncertainty and confusion about what the current state of the specification or standard actually is. Which means you have to increase immensely the work that goes into researching the current state of the standard, then creating and testing x-number of versions of your product for platforms that are at y-state of compliance with the ever-changing, and therefore never fully known, state of the standard. Efficiency and productivity get hammered.

        So it does make a difference. Yes, even if you version HTML by the year: HTML 2012 or whatever, it hurts nothing, but can help everyone.

      • The trouble is that no browser will ever conform to the full standard. There will always be quirks, bugs and subtle differences.

        So Mozilla report that their browser covers 98% of the HTML-X spec. Google reports 99%. Microsoft reports 95%. You still need to know which pieces are missing and code around them accordingly.

        HTML version numbers offer no absolute certainty. The HTML5 spec is being continually revised and, even when it’s “complete”, vendors won’t necessarily have implemented everything.

    • Anonymous

      This post is the work of a genius.

  • Antonio Kobashikawa Carrasco

    IMHO it may be good for work in some level but not for reference (what is part of work in many other levels). What if you search HTML in Google? When I search HTML5, it is easier.

  • This is ridiculous. My website is a living document, so is WHATWG claiming that best practice is to eliminate version control? So the history of the site is irrelevant? Any professional developer, including myself, would think that I’m an idiot if I didn’t have my site under some form of version control. And now the most important foundational document in IT is throwing versioning to the wind?

    Versioning in fact gives everyone key touchstones. Does any browser support HTML4.01 properly? No, but at least we have a definition for what HTML4.01 means! So we can say that browser X supports 4.01 but with this list of exceptions while browser Y supports 4.01 with a different list of exceptions, and browser Z on a crappy mobile can’t hide the fact that it’s not 4.01 compliant at all. The spec is now a moving target which means we have no common reference to refer to. Unversioning the spec doesn’t turn it into a living document, it eliminates our ability to use the spec as a common definition of what the technology “HTML” means and to use it as a touchstone when we communicate with each other. This is a disaster.

    Should you use modern best practices? Absolutely. Should you stay current in the technology? Definitely. But how does that free us from the need to be able to talk to one another about what we’re doing? Ask someone if CSS2.1 works with HTML. There is no longer a way to answer that question unless you are on your mobile phone looking at a copy of the “living” spec. And when you say “yes” it is a highly conditional answer because we know the spec may be updated in 2 minutes in a way that changes that answer.

    I can believe that with the problems the W3C has had in recent years, they are looking for new ways to get some kind of control. Too often the browser vendors have bullied the W3C into rubber-stamping bad policy. Too often, the W3C has been frustrated in its goals and had to reverse course. The abandonment of XHTML2 is but one glaring example of the failure of the W3C as a policy organization. But dropping version numbers clearly isn’t going to solve any of these issues, and the damage it will do to our ability to communicate with one another is shocking.

  • Tim

    Surely they must still have the concept of drafts in there somewhere? Otherwise the assumption is that all things in that document are complete and ready for prime time, or worse, they could be there today and gone tomorrow because it is a living document. I don’t care about the version number per se, just the quality control process and reality around it.

    • If an HTML feature appears in the specification, it means it’s already been implemented by 2 or more mainstream browsers. It’s not likely to disappear.

  • Vin

    Why do you use CSS 2.1 and 3 as a comparison when making a case for lack of version numbers. Instead lets look back at the HTML 3 to 4 transition. Version numbers and browsers moving toward compliance with a new standard was pretty key, and even played a pretty important role as the browser wars took shape and evolved.

    I’m pretty certain that the notion of a living document is a mistake as we try to bring modern browsers under a single umbrella.

    You make the statement that losing the version numbers is in accordance with the current state of the web, but maybe that’s the problem. The current state of the web is not a coordination of efforts, it’s a mish mash of different technologies in many different browsers, all in various states of completion. Thats what makes web development a nightmare.

    Working toward a marked and complete standard, even if it is only “DRAFT”. Still sets a scope. Something an IT team coding a browser would absolutely want to see. Who develops without a scope?

    • If I remember correctly, the progression from HTML3.2 to HTML4 was a non-event. Browser vendors did what they liked and were in active competition. The W3C was new and few developers knew about or adhered to web standards.

      I think the “draft” stamp is the root cause of the problem. It will remain for years and gives the impression that HTML5 can’t be used.

      There’s still scope with a living document. If you’re creating a new browser, you can take the HTML spec and develop a rendering engine based on those requirements. That spec will change, but that’s an inevitable part of IT.

      • Vin

        It’s my recollection that only ONE browser did what it liked. Additionally if you mean non-event as in there was no marketing hype around the 3 to 4 transition, then I agree. Much different

        But, as for moving toward a more complete standard, and giving browser developers a focus, I think it was a pretty significant event.

        The draft stamp isn’t what bothers me… its the “living document” part. An ever evolving scope is an out of control and unachievable scope.

      • Do you remember layers in Netscape? Awful technology.

        The HTML5 specification is already a living document. It may take years to complete because features are being added. Removing version numbers doesn’t change anything.

  • Cogito

    I’m not crazy about dropping the digit. For me, I don’t care, my concern is doing awesome things with the API, but when I talk to people, clients, etc., and I say “Oh, I use HTML5 API…”, it sounds better. Millions of people can say “I know HTML”, but only a handful know HTML5, taking away the digit takes away its significance.
    @moneymark It’s impossible to say “This is HTML5, let’s move on”, because the spec has been split up so much, not to mention web storage getting its own spec. Each module, like CSS3, is being developed independently of the other as regards their importance to the browser makers. HTML5 might not be fully implemented for eons, so waiting for v6 is not a wait I would envy. ;)
    @eric I think the HTML5 API, while oft times word heavy, is better than most previous ways of doing things. Between it and the new properties in CSS3 I’m sure libraries like jQuery will be relegated to the role of “workhorse”, moving out of that whole fun animate-the-crap-outta-everything role, and into a heavy-lifting-ajax-centric role. You can already see this with node.js.

  • moira2010

    What doctype do we use? I’ve just started to,learn more about HTML(5) and put will this still be correct. Up to now I’ve used xhtml, am fairly new to web deveopment.

    • If you’ve moved to HTML5, the new doctype is <!DOCTYPE html> — it’s got no version number. I doubt we’ll ever see one added.

      • aking10

        But this just points out the problem of now dropping the version number. Now you can’t say to someone, “have you moved to HTML5”, because according to the WHATWG, it is now just html. So if a newcomer to the field types simply “html” between the angle brackets, does that developer know what he or she is getting? Will that developer know why there is a difference between just typing an html tag and the “!doctype html” tag — because if it’s all just called html now, the difference will not be obvious. And how will the developer know what the term html refers to next year or five years or nine years from now? It will change — but without versioning, everyone will be less certain about HOW it has changed.

      • You’re using <h1> tags in your pages, right? H1’s been in HTML from the start and remains in HTML5. Tags added to the HTML specification are never removed: some become deprecated, but your browser will still parse them.

        The fact is that you can slap an HTML5 doctype on any page and call it HTML5.

  • When I look at the code someone else has written, or which I had written a long time ago, I want to be able to see with just a glance what standard the document has set for itself. That is impossible without something like version numbers. How else could it be done? By comparing dates? That just sounds painful. File hashes? Even more painful. Do you want me to not know what standard the documents have set for themselves? That just sounds awful. There absolutely should be version numbers and there should also be a fairly long period of time between each increment of the version number so there will only be a few that need to be remembered.

    • How do you know which standard the HTML5 doctype refers to? The only reason it matters is for your peace of mind. Browsers don’t care and nor do users.

      Are you updating all your HTML4 sites to HTML5? Sites developed 10 years ago should still work today. There’s little reason to update your HTML code unless problems occur or you’re doing a full redesign.

      • aking10

        Your statement: “How do you know which standard the HTML5 doctype refers to? The only reason it matters is for your piece of mind. Browsers don’t care. . . ”
        is incorrect. Browser makers have indeed cared, and worked very hard, to show that they were approaching the HTML5 standard and to demonstrate how much of the standard they were implementing. It was the point of having the standard and giving the standard a version number!
        And since when is “peace of mind” (correct spelling) a bad thing? Developers have enough stress to deal with already — the ambiguity and uncertainty going forward about what html is and means “today” is not going to make developers’ lives any easier at all.

      • Browsers don’t care. If we ignore IE for the moment, browsers only know whether they’re in standards or quirks mode. Try adding a <nav> element to an HTML 3.2 document … the browser will still render it and append it to the DOM. They won’t validate your code and decide to remove the element because <nav> wasn’t in the HTML 3.2 spec.

        I’d still be interested to know how version numbering makes your life easier (spelling mistake fixed, thanks). Many developers appear to think that a big switch will be flicked when the HTML5 and CSS3 specifications are “complete” so developers can use the technologies.

        It doesn’t happen like that: the move is gradual. Some features, like Canvas and CSS3 rounded corners, are usable today. Other features less so.

  • Steven Clark

    Bad idea… but then I’m from a software engineering degree with a web design practical background. It’s a bad idea because it’s not addressing the underlying problem – that a benevolent dictator using a populist model can work… everyone will always want more features… so the answer isn’t to drop versioning it’s to draw a line in the sand and say “this is the spec here” and evolve forward (much what moneymark has said).

    The other facet that worries me with a live document is that what I read on one day may become untrue directly afterwards because there is no guarantee that Hixie hasn’t chosen to change the live document to add or remove the feature. So what use is that to me? If I can’t rely on it? And what use is that to two people trying to have a conversation about what is in the spec… as they would have to continually stay up to date with every nuance and change that occurs? That’s why it makes no sense.

    So while it may be the populist modern idea to do this and I concede it sounds romantically attractive on some level… it means you don’t have a specification at all. Because nothing ever gets truely specified. I’m not sure the argument that specifications aren’t ever fully implemented anyway is the natural progression of reason to drop version numbers either.

    But hey, that’s me. We’ll have to agree to disagree.

    • Steven Clark

      Sorry, that should read “that a benevolent dictator using a populist model can’t work”. Typo :-0

    • Tim

      I agree…with no version number, it’s like walking on marbles…an ever-changing landscape (er, living document). If it can change so easily, I don’t see any real need for either the standards body or coding to standards.

    • Hixie

      Version numbers on the spec don’t give you a guarantee either. There’s tons of stuff in HTML4 that is different in HTML5. It wasn’t because I decided to change them, though, it was because they were either flat-out bogus in HTML4 (e.g. the requirement to not assume a default encoding), or the browsers decided to implement something different (e.g. the default value of the media=”” attribute), or too vague in HTML4 (e.g. parsing rules).

  • Damn, does this mean I can’t coin the phrase “html7”? I’ll just go and create another buzz word… “web 5.0″… “hcjappi” (html/css/js/api)… ok, I give up.

  • W2ttsy

    This just further cements my thoughts on 1 render engine, n chromes.

    No one uses a browser because it renders things a certain way. We don’t choose IE or Firefox or Chrome/Safari because they render a page a certain way. We choose a browser because it has features and tools. The render engine plays such a small part.

    We choose chrome because its light weight, fast to load pages and also has tab based cpu/memory partitioning.

    We choose firefox because of extensions, developer tools and its more secure.

    We choose IE because its what ships with windows and many people are happy with what it offers.

    I propose that the W3C spends its time developing an engine that all vendors use and contribute back to.

    If MS wants to run a ridiculously stupid 2 year build time on their browser, then what does it matter if the chrome and tools are 2 year cycles, yet a software update will put down the latest render engine.

    If open source contributors wanted to continue to improve the engine, then why not? Let them. The firefox experience wouldnt change if they went to web-kit, and nor would chrome or IE if they swapped to gecko.

    Having the three render platforms is probably even more dangerous now with an unversioned HTML spec. For this to work, the W3C should be building the render platform to match the ever changing spec and then publishing that engine so the browser vendors can use it.

    Then let any vendor use that standard engine with whatever features they want to insert into their product.

    The “competition” between vendors isnt surrounding the render engines, its surrounding feature sets. Who can get a faster browser with better bookmarking and smart toolbars.

    • Active competition pushes the web forward. I agree that the rendering engine plays a small part in a user’s decision to use a browser, but innovation could stagnate if all developers are working on one codebase.

      Besides, people will always disagree about what’s the best or most important. Before you know it, the W3C engine will be forked into a competing project and we’ll be back where we started.

      It’s amazing how close the rendering engines are today (especially if you’re old enough to remember the dark days of development 10-15 years ago). Personally, I’m glad we have the variety — it may make development challenging at times, but no one vendor has too much control.

  • catbarnes

    I wonder what John Allsopp thinks about this. His “HTML5 Live” Sitepoint courses were excellent and gave me the courage to jump in and start developing small sites using the new syntax. If his course had simply been called “HTML Live” It probably wouldn’t have caught my eye, and I wouldn’t have purchased it. Same goes for “HTML5 for Web Designers” and “HTML5 Now”.

    In my opinion some things need some marketing to catch fire, and this certainly worked for HTML5. Which in turn was great for getting the Web Dev community together and pushing the new standard out into the open.

    By the way, I’m proud of myself for taking the incentive to learn HTML5. And I’m keeping it with the version number on my resume!

    • HTML5 has become a marketing buzzword. Unless you’re talking to a knowledgeable developer, it bears little relation to the HTML5 specification. I don’t particularly like how it’s been hijacked, but I’ve got over it and there’s little anyone can do to change the perception.

      Even the W3C are calling HTML5 a catch-all term for modern web technologies.

      • Brent Lagerman

        why is that a problem? Marketing new web technologies is a good thing… Google has been hyping the hell out of HTML5 and they’re obviously not ignorant to what it is. If it gets people interested in standards, accessibility and semantic markup (which HTML5 is all about) — it’s good.


      • It’s not really a problem … it just makes developers cringe! Like Web2.0 and Ajax, HTML5 has become a meaningless buzzword. However, unlike Web2.0, HTML5 also refers to a specific technology.

  • Victorinox

    This thread at makes interesting reading.

    • Cogito

      Thanks for that link. I think Joshua is right in many ways, but I also think that HTML(5) becoming a living spec might also give the browser vendors a lot of leeway. The browser makers are generally fairly savvy enough to know what’s good (with the exception of the other one, you know the one) for them, for us, for our clients.
      Look at it this way, the spec was in flux anyway, right? User agents were just gonna go ahead an evolve at their own pace regardless… so nothing has changed, really… Well, unless I’m painfully mistaken.

      In any case, I think time will tell. :)

  • aking10

    @Craig, who in one reply above says: “I’d still be interested to know how version numbering makes your life easier” . . .

    Alright then, for argument’s sake (and this will be my last comment, I promise), let us say that calling the new spec HTML5 did not make my life any easier. A new HTML standard made it more interesting, but not much easier.

    So tell me this: whose lives, then, have now been made easier by removing the version number?

    What has it clarified that was unclear before?

    What problem was so bad that removing the version number was required to fix it?

    Has removing the number from HTML5 fixed or solved anything at all for the web development community?

    Who, other than browser makers, really benefit from this move?

    • If we remove the version number, there’s no draft status.

      In this situation, draft means that the specification document is a draft — not the technology it refers to. Unfortunately, many developers equate draft with “not ready to use”. That’s not necessarily the case: a feature within the HTML specification must have been implemented by at least 2 vendors.

      If there’s no draft, more developers will be tempted to use the technologies. They may find browsers which don’t support it or have an incomplete implementation — they’ll publicly complain and the guilty vendors will have to listen or prioritize accordingly.

      If anything, the version numbering can hinder browser development. Currently, a vendor can state they’re waiting for the completed specification before implementing a feature we all want.

  • Brent Lagerman

    makes sense, but a lot of traction was given to HTML by HTML5, even though it’s technically just an evolution of HTML it’s marketable and people can get behind it… Seems like a dumb idea to take future numbered releases away…
    anyway check out our wordpress HTML5 shell :D — >>

  • Benyp

    After all those years, I finally gave up on the evolution of features of HTML. MY point of reference is simple: I’m developing using IE6 :)

    If it fits in IE6, it fits everywhere! The evolution and increase of features of HTML is just too dependent on web browsers’ developers (ie, Google, MS, Firefox). Sometimes I wonder if it wouldn’t just be easier to let a single authority literally dictate how HTML should work and behave. Is it normal most browsers can’t even support video yet Flash had it for years? Yes, my friend, that’s what happens when too many people work on an open standard at the same time :)

    • Think back a few years when there was one mainstream browser and one organization did dictate standards. That led to the very reason why you’re still supporting IE6 10 years after it was released!

      • BenyP

        Good point Craig. But the problem did not start because MS was not bringing innovation, it started because everybody started pulling the cover on their side (think Netscape vs IE). Had MS kept leading the way, i’m sure we wouldn’t have been out of innovation. My point being, I really don’t think WHATWG is the most effective way setting standard and leading web innovation. Really, all those years to bring rounded corner and drop shadow? (Note my sarcasm… they did also bring and type=’email’ box and innovative side stroller selector (keep noting my sarcasm : ) … )

      • Actually, Microsoft considered the browser to be a dead concept in the first half of the last decade. They backed Windows-based internet-connected smart clients which would offer slick interfaces with the benefits of web services. The company disbanded the IE team and announced that IE6 would be their last browser release. Updates would only be available if you upgraded the OS.

        What MS didn’t foresee was the rise of browser competitors and Web2.0 applications. Even then, it took a couple more years before IE7 was released.

        While a single browser appeared to have benefits for developers, it put the evolution of the web back several years.

  • Paul McKeown

    The whole thing is about raw politics, a power grab by Hickson. The rest is ex post facto rationalisation.

    • Ian Hickson’s already a specification editor … how much more power does he need?!

      • Paul McKeown

        Oh, just the authority not to have to listen to anyone else at all. Remember his comments about benign dictatorship? Many tyrants see themselves as wise and acting in the common interest; it almost always ends in tears.

      • Hixie

        “Specification editor” is actually a remarkably powerless job if you do it right — meaning, if you commit, as I do, to specifying what the browsers and other implementations actually do. It’s the implementors that have all the power. An example of this would be the handling of MIME types for the “video” element. I specced that the browsers should honour the HTTP MIME types, but most of the browser vendors disagreed and instead want to sniff. So they implemented sniffing, and ignored the spec. Net result: I’m going to have to change the spec.

        I don’t seem to have the ability to reply to Paul’s comment below, so I’ll reply here as well: I’ve committed to reply to every e-mail with substantial feedback sent to the WHATWG list, and I track the amount of e-mail pending very carefully ( I also give a personal reply to every bug raised in the HTMLWG. I have no intention of ignoring feedback. The whole spec is built on feedback.

      • Paul McKeown

        I think the point is well illustrated by Kyle Weems’s CSS Squirrel. See, for instance. with an explanation

        I know that that issue of Weem’s comic is old now, but the point remains valid.

        The whole idea of HTML losing its version numbers is quite old (ca. 2 years) now.

  • momos

    I read here that the W3C is behind with their specs, but when they are running ahead (with XHTML 2.0), browsers won’t follow, so they have to run behind, but a spec makes sure that everyone is on the same track, and can strive to the same milestones, while without versioned specs the web can evolve in different directions. And in such a situation the biggest browser maker is always right…

  • The problem is that HTML5 is not a specification but a summary of specifications that each of the browser implementors have (does anyone believe that the engineers at Microsoft or Google don’t know precisely in which version what tag was made available???).
    That HTML5 document, unlike the previous ones, accepts that it merely documented the features the different browsers have implemented so far. This is important work and a very important tool for us.
    If you look at it from that perspective the WHATWG is right is wanting to drop the single digit version number from their document since the actual version number should look like “Gecko1.9.2.13-Trident9.5-Presto2.7.62-Webkit534”. At the same time we should stop calling it a “specification” since it is not one and use the term WHATWG has coined which is a “Living Standard”.
    Should it be numbered? YES? Is it numbered even without the 5 in there? YES… the whole document is layered with meta information indicating which version of which browser supports which feature. Will dropping the “5” reduce confusion? NO but it sure raises awareness on the reality of that document which is that it provides a central point to know what’s available in HTML and the state of that feature in the major browsers.

  • Christmas on a cracker the idiocy continues — Just TRYING to prove that the people behind it had no clue what the point of STRICT is, how to maintain clearly defined rules, or even make it so that new versions and timelines can be maintained?

    Who’s running the W3C right now, Bozo the Clown? Four year liberal arts students?

    When I called HTML 5 the new HTML 3.2, I was really on the money — and this just further proves it… So sure, go ahead and vomit up code any old way and slap billions of new tags in there for no good rason like the height of the browser wars — why not?

    I had no plans to embrace HTML5 given it’s sloppy half-assed hodge-podge of “rules” (or more specifically lack therin) and over the top pointless redundancies… This is just another step to make sure that anyone with more than two neurons firing won’t touch it with a 50 foot cattle prod.

  • Adelante

    Interesting thread, my first thought was ugh anarchy!!! But I stopped and thought, how could it be better and what would I like as a web developer for this standard to have.

    The only way I can see a dynamic standard working is every feature along with implementation information needs a compatibility listing indicating what browsers it works on, much like Sitepoints excellent HTML reference.

    In doing so web designers can decide what features they want to use based on their market, browser support and trends. Eg: someone marketing to young professionals can take advantage of features offered by modern browsers where a market that has useability requirements should avoid certain features.

    Another interesting thought is browsers should be depreciated, at a certain point the standard stops supporting old browsers. This would be when a browser has reached a certain age, has a very low usage or retricts the implementation of a significant html advancement. A date would be set, mainstream media informed so that all consumers are aware and can upgrade. I’m not saying that this would be quick but it would be better that the leap of faith approach we have dropping IE6 support.

    What else should the HTML standard feature? Perhaps what we need is a new standard for implementing standards ;)

  • momos

    Maybe a yearly snapshot spec is an option. All the stable additions are in there, points of discussion are left out. That way you keep evolving at a steady pace, but you still have a spec to fall back on, and to witch all browsers can comply in a near future. No browsermaker will want to claim eg. HTML 2004 compliant

    • I agree — there could be a retrospective version snapshots at various intervals. Unfortunately, it’s not that clear-cut. No browser is likely to fully support HTML 2011, but it may also implement new features that will appear in HTML 2012 or later. Marketing spin will add to the confusion.

      I think Adelante’s suggestion of a document which lists compatible browsers for every feature would be a far more useful concept.

      • I agree that a listing of compatible browsers is one very useful resource. Peter-Paul Koch’s great website includes such a list and it’s the most popular part of the website. That level of detail is great when you are trying to code, but it is absolutely horrific when you’re trying to have a conversation with someone. HTML can and should evolve exactly as it always has (version numbers have never affected this development either speeding or slowing anything).

        Is the W3C’s process of vetting new innovations bizarre? Yes. Is it tedious and unforgivably slow? Absolutely? Is it riddled with vendors bullying bad practices into the standards? Definitely? And the solution is…

        dropping the version number????? Are you serious?

        That’s not going to put any more guts into the W3C to fight for innovation that doesn’t jive with the marketing dept. at Microsoft (or Mozilla for that matter). The version number has never been the thing that makes things take forever in the drafting process, it’s the infighting of the different groups. At least today, it is glaringly obvious when they haven’t produced a new specification in several years. A “living document” means that there will never again be a finish line or a due date against which anyone can be held accountable for their non-performance.

        Another more minor point, if this system had been in place several years ago, would MS ever have moved beyond IE6? Certainly not. It took years for MS to notice, but they finally became embarrased that their browser was maligned for not passing the ACID2 test. When they finally moved, they not only came out with a new browser, they trashed IE7 in a matter of months because it didn’t meet the benchmark. Now we are supposed to face a world where you can’t construct and ACID or any other test, because the spec is “living” and changes every other day? I would seriously like to see someone go to their boss and argue that testing is no longer necessary because they want to unversion their software for “maximum innovation”. This isn’t going to improve the pace of innovation, it’s taking the tortoise that is the W3C and telling them they no longer have any due date for future project enhancements. I would be embarrassed to be part of a shop that works like that, and I find the idea that my primary standards body would take this position to be nothing short of tragic.

  • Yes, likewise, I think Adelante’s suggestion is a good one. My first reaction to the dropping of the 5 was horror, but on second thoughts, HTML5 isn’t so much a different animal from HTML4, but rather HTML with some extra features (so far as I understand it—though I gather there’s more to it). So it’s really about features, rather than a different language, so why not just document what features of HTML a browser supports, rather than worry about an arbitrary version number of what is essentially just the same thing—HTML.

  • johnywhy

    How does a version number make the spec a “dead” document? It doesn’t. The version number does not mean “this document is set in stone and may not be changed.” It’s just a convenient point of reference.

    Fine, call it 2012, that certainly carries more information than the number “5”.

    When the spec has such dramatic additions as this one, it’s just helpful to be able to refer to the spec at this point in time. A version number does not “kill” the document.

    How can we call it a “specification” if it’s, as the author says, simply an after-the-fact historical document, describing what various manufacturers decided to include? If it’s not a spec for software makers to follow, maybe we should not call it a specification at all.

  • Sergey

    So, should I now rename my HTML5 book? Should I call it “HTML” book? I don’t think so. We need to retain versioning.

  • Meh

    Now we just need a rewrite for the English language and drop versioning!

  • Web kid


    I am also doing the HTML5 Live course I am
    finding to be great.

    all the best
    Web Kid

  • Curt

    So far, there was no need for me to use HTML5 for any webside.
    But this sounds horrible, but may be all vendors should also remove their version number and just call it Internext Explorer, or Safari.
    And let is see how it ends …

Get the latest in Front-end, once a week, for free.