HTML5 Renamed!

Wow, I was pretty amazed to hear that the WHATWG (the group leading the HTML5 charge) has decided to drop the “5” in the name and just call it HTML from now on—on the grounds that it’s really a “living” and evolving standard that shouldn’t be pinned down with a version number.

SitePoint has already blogged on this, but I thought it would be fun to continue the discussion here, if any one cares to.

At first, I was shocked by the news (which came a day or so after the W3C unveiled its shiny new HTML5 logo!). But after some consideration, I’m starting to think it does make a bit of sense … though it will make life difficult in that it will now be harder to identify what’s new in HTML without a buzzword … unless we’ll just keep the buzzword anyway (but it won’t be quite the same). I won’t repeat all the arguments that others have already put, though. Here are a few I’ve read, such as:

Ian Hickson’s announcement and people’s comments
Jeremy Keith’s take
Zeldman’s take

It wasn’t really a decision. It is meaningless for HTML to have a version number and I would argue this is the way it’s always been. Tying HTML to a number never made any sense.

edit: Also, it won’t be difficult to identify HTML5, because HTML is simply HTML. Whatever version of HTML is being implemented is what the term “HTML” refers to. That’s all there is. It’s the only option anyone has. You couldn’t opt to use HTML4 over the current standard of HTML even if you wanted to.

Yep, I’m inclined to agree with you. The new doctype kind of made this inevitable, I guess (as people say in the links I posted):

<!DOCTYPE html>

With a doctype like that, the version number does seem a bit out of place.

I’ve officially renamed it “Fred”.

I wasn’t surprised it has been obvious for several years it was probably going to be the last version but it won’t matter now because anything proprietary you write will be 100% correct.

A stupid move just to get attention.

Of course HTML is and will be HTML. Those 3.2, 4.01, 5 where put there to differentiate details about it. We are all humans. Should we lose names and called one another: “Hey, Human, the Human leaving on the Street in the City said the Human on the Street in the City met with the Human on the Street in the City and then together they met with Human on the Street in the City and then go to the Street in the City”. Go figure Human :wink:

Yeah, UAs don’t care. But I, Human, care :slight_smile:

The Web Standards Project has spoken (see left column, under “On a related matter…”)

“…we stand by our sentiment that the final (as in W3C) version of HTML5 should continue having a version number while the version-less WHATWG version is used for continuing development.”

But I would like to communicate that my site uses some features only implemented in HTML7, without having to worry about having fallbacks for older browsers like Firefox 6 that aren’t aware of the new standards.
How will the browser know if it meets the minimum requirements if there is no way for the site to declare them?

This wouldn’t be an issue if everyone kept their browser updated and all the browsers met standards and held backward compatibility, but this is the real world!

As a standard that never really throws anything away, I wonder if, for certain applications, HTML has outlived it’s usefulness.

The web applications we build tomorrow look to contain fairly sophisticated graphical effects and the like, but I’m wondering how much processing time is wasted by the browser trying to allow for all sorts of markup.

I mean, nothing ever goes away in HTML, and the browsers that have the worst mistakes in their history - the IE family - has been plagued with the effects of shedding off options never part of the standard. But the standard itself has had trouble shedding off things that were a bad idea or have been eclipsed, such as the layout tags <center><font> et al, or the frameset tags.

In the end we have 6 core machines just barely providing better performance than machines from 12 years ago to a degree because of the outright crap the browsers must sort through to get to valid code.

And the problem is compounded by the fact that when a site fails to display most users blame the browser (if they are aware of what a browser is). This dates back to the first web war between Netscape and Microsoft. Every browser wants to be the hero - reading through the code and bending over backwards to try to resolve and execute at least some of the bad code.

XHMTL was supposed to fix this with a stricter syntax, but Microsoft’s failure to implement it correctly stillbirthed it and made it a joke.

HTML is with us and will be here to stay for a long while, but I can’t help but wonder if it should be left behind by professionals in favor of a stricter markup language that has an emphasis on the speed by which the browser can parse it - the result being driven by two factors. First, version numbering that means something - and major version numbers of the standard have NO obligation to be backwards compatible so that there is a mechanic to remove bad ideas from the standard (Cause face it, in 20 years someone is still going to be putting <center> tags in the webpage).

This would unlock a lot of processing power wasted on HTML’s shortcomings, ambiguity and bloated state that is, frankly, NEVER going away. Maybe its snobbish of me to say so, but HTML should be left to the amateurs who dabble on the web and professionals whose livelihood depends on accurate and faster results should get a markup language that delivers that speed. Similar enough to HTML not to be a pain to learn, but unforgiving in its parsing such that if you don’t close a tag that should be closed, you don’t get a page, and so on.

The world needs both. I wouldn’t have learned what I have if HTML was unforgiving and difficult to use. But I have progressed beyond such childish coddling and now it’s getting in my way. I’d love to have a markup language that doesn’t display until it’s valid. I’d love to have a scripting language that allows me to set a variable’s datatype as needed and which doesn’t contain legacy calls to support half a dozen technologies no one uses anymore.

At some point I think the legacy garbage in HTML is going to stifle it’s growth to the point where this divorce between amateur markup and professional markup will be forced.

As for the drop of version number of HTML, this is VERY dangerous. It is a return to the situation as it was in 1996. If HTML doesn’t have a version number then people will begin to code to browsers again. With no milestones version numbers to mark features that can be expected to be found across multiple browsers, we will see a return to the days of “Site best viewed in [insert web page owner’s pet browser here.]”

While browser implementation of standard versions has never been perfect, it gave you a ballpark estimate of which browsers would run the page. Without the version number it becomes a blind guess.

It isn’t that they failed to implement it correctly but rather that they left it to IE9 to implement it. Once IE8 and earlier drop to a small enough percentage of users then using XHTML properly will finally become a practical alternative. Since this will happen long before the new standard for HTML is finished it will mean that by the time all the new mess with HTML finally eventuates with an actual standard that few will still be using it.

As I said, stillborn.

How does ‘stillborn’ define something that all the latest versions will support at the end of this year (or whenever it is that IE9 is released).

Once you can ignore IE8 and earlier and rely on your visitors using Firefox, Safari, Chrome, Opera, or IE9+ then you can use XHTML properly.

It shouldn’t take too many years for IE8 to disappear. Certainly far fewer years than it will take for the new version of HTML to become an actual standard.

Or are you suggesting that this will result in the new HTML being stillborn because everyone will have switched to XHTML?

It does not matter whether it is HTML5 or simply HTML. The working remains the same.

But just calling it HTML or HTML5 and posting the specs isn’t enough for it to “work”. Browser makers have to implement it. Some argue that not having a definitive version to work towards may give browser makers an excuse not to bother adding “HTML5” features, as the browser makers can say “sure, we support HTML already”. I don’t know if that will really happen, though, but I can see their point.

The name of this new technology could have quite an impact on its future.

With no milestones version numbers to mark features that can be expected to be found across multiple browsers, we will see a return to the days of “Site best viewed in [insert web page owner’s pet browser here.]”

CSS3 has already created this need. “Best viewed in Chrome” is one I’ve seen in multiple places, just not on a badge.

If IE9 isn’t going to get ported to Windows XP, you have a good 10 year wait for IE8 to die.

Wow, I’m surprised too.

HTML5 is quite well known in the public already, perhaps from things like Steve Jobs using it to defend Apple’s position against flash on the iPad / iPhone.
Having such a well known name I don’t know why they think it’s a good idea to remove it.

I’m with BlackMax - The spec formerly known as HTML5 is now Fred.

Now that you’ve mentioned Apple, couldn’t we at least go for something like Leopard / Snow Leopard etc? OK, cats are done, so what about dogs? How about HTML5 be Labrador, and the next version Greyhound … or maybe Dachshund, Chihuahua, or even Poodle … :frowning:

Psh, they’re just copying Ubuntu’s crazy names, lawlz. Yeah, I’m still on Karmic Koala. Have to upgrade to Lucid Lynx soon.

That was part of the problem. Jobs pointed to some CSS3 sites and called them “HTML5” which started the whole “everything that’s new and cool on the front-end is HTML5” which elicited Bruce’s awesome rant among other things. ([url=]NEWT)

Every time someone writes some Javascript on a page with a <!doctype html> at the top is getting called “HTML5”. Though I don’t see why the name couldn’t still apply to markup.

I found that the version of HTML supported by my Firefox 3.6.13 is HTML5.

I think this is a very valid question. But don’t browsers have quirks/standards mode to deal with this kind of thing? Presumably, in standards mode it can ignore (at least to some degree) invalid/outdated markup. Which brings us back on topic. Without a version number, how can the browser know what is/isn’t valid? I can start using <section> and <article> tags but how should the browser handle them? The HTML spec says that unknown tags should be ignored… which is what IE does, and they can’t be styled (Without a javascript workaround).

In some ways this is where XML/XSL had it right, it let the developer at hand define what they wanted on a per-page basis so browser support of specific tags is irrelevant, of course it’s far from practical in the real world and I also feel XHTML was a healthy middle ground.

While browser implementation of standard versions has never been perfect, it gave you a ballpark estimate of which browsers would run the page. Without the version number it becomes a blind guess.

Couldn’t agree more. Sure removing the version from the current standard makes sense if it’s going to be the last version. What about in a few years when there is need for new features? How will we as developers be able to use them? Browser sniffing? It all seems a bit messy to me.