No More Version Numbers For HTML

An anonymous reader writes "HTML5 will be the last version of HTML that carries a version number. Ian Hickson, a Google engineer and editor of the HTML5 standard, announced that the language will be transitioned to a 'living standard' without version numbers. A bit like Chrome, if you will."

Comments

Not a Standard.

[Anonymous Coward]

If you never finalize it's not a standard. This sounds like a Microsoft move to me.

Re:Not a Standard.

[Anonymous Coward]

It sounds like an article in the tech section of The Onion.

The nice thing about standards, is that we have so many to choose from. Or none at all. It's HTML, Jim, but not as we know it.

W

Re:Not a Standard.

[Anonymous Coward]

The real reason is because the committee which desides whats in the standard couldn't get a consensus, so HTML 5 took forever and its still not a W3C recormendation.

Look at http://www.w3schools.com/w3c/w3c_html.asp

HTML 4.01 became a W3C Recommendation 24. December 1999
XHTML 1.0 became a W3C Recommendation 20. January 2000
On January 22nd, 2008, W3C published a working draft for HTML 5.

So 10 years after xhtml 1.0 we still dont have a W3C recormendation for HTML 5, if HTML 6 carried on business as usual then we would probably be looking at 2025 for it...

Re:Not a Standard.

[Anonymous Coward]

If you never finalize it's not a standard. This sounds like a Microsoft move to me.

Not a Microsoft move. It's a Google move. Google is Evil.

Ian Hickson (Google, ian@hixie.ch) part of the Web Hypertext Application Technology Working Group (WHATWG), which develops HTML5 together with the W3C.

Re:Not a Standard.

[Anonymous Coward]

WHATWG HTML was never a standard anyway. Nor is W3C HTML5 since their logo committee redefined it to mean "everything under the sun that is new and remotely web related". Someone whose brains are still intact (such as Sam Ruby) should invent a new acronym for HyperText Markup Language and trademark it to protect it from stupidity.

Re:Not a Standard.

[nschubach]

Sure it is. The standard is what is currently on their page. If you are using deprecated methods, you are non-standard.

You could be standard compliant one day and be out of compliance the next.

Maybe it's better if I put it this way. There's a new standard every day. It's just the nobody puts a version on it.

Re:Not a Standard.

[BoberFett]

That will truly help the industry, when contracts calling for levels of compliance become impossible and designers can never get paid because their work is never compliant.

Re:Not a Standard.

[Anonymous Coward]

I though the Microsoft way was to whinge about how they couldn't implement any features because they weren't standardized, never mind that the standards are developed in cooperation between the browser vendors, and at least two vendors must implement something before it is viable for standardization. (One of the things that blocked the Web SQL Database proposal.)

Re:Not a Standard.

[Daniel Phillips]

I've always thought the stewardship of html to be fairly idiotic and this just supports that point of view. Like you say, a perfect opening for Microsoft or whoever else chooses to be evil.

Re:Not a Standard.

[wesleyjconnor]

if it takes them 10 years to get a standard ratified, what did we do in the meantime?
a rolling standard is at least worth a look

Re:Not a Standard.

[Anonymous Coward]

I'm pretty sure even the Metric System is still open to revision. Most of the time for convenience sake they revise to fit what they already decided, but it's hardly set in stone...iridium, sure, but not stone.

Re:Not a Standard.

[sdiz]

You missed all those XHTML 1.1 Modules. That's how W3C wasted all its time.

Original HTML5 draft came from WHATWG, not W3C.

Re:Not a Standard.

[Anonymous Coward]

So... will HTML have build numbers?
HTML build 2280

Re:Not a Standard.

[Gadget_Guy]

never mind that the standards are developed in cooperation between the browser vendors, and at least two vendors must implement something before it is viable for standardization.

That was the old way of doing it, when Microsoft and Netscape kept adding more and more features in the hope that it would make it into the standard. Think tables, frames, blink - oh wait: thank god it didn't work for blink!

These days it is frowned on to add features that are outside the standards, with a few exceptions like styles with prepended browser identifiers and things hacked into meta tags (like iPhone's ones to control the layout on the small screen which I think should have been a custom style).

However, you are correct that the Microsoft way is to stick to the finalised standards rather than the ones that are still in flux. I think the reason they did this was to avoid a repetition of the box-model saga, where IE had to implement a box model before it was spelt out in any standard. But when the standard went a different way, they were stuck being incompatible with the rest of the world.

This wouldn't be a problem if the standardisation process didn't take many years to finalise. The HTML standard needs to improve in small increments. Not too small, or the browser manufacturers will always be playing catch up, and the user would be expected to upgrade every single time a new version was released. But not too big so that it takes 5-7 years for a standard to become official.

Re:Not a Standard.

[davester666]

No need for version numbers anymore because...

they are switching to version letters!

Next up: HTML.f

Re:Not a Standard.

[cgenman]

To be fair, the prior versions of HTML were all pretty bad. By HTML 4 the kinks were pretty much ironed out, but with some kruft that XHTML stripped out.

HTML 5 is a major undertaking to rewrite how HTML works in a radically different way. That does mean that nobody will agree. That's the nature of technology as it matures. At first it's terrible, and has frequent updates and releases. Later, as it matures, the updates are slower and more thought out.

Re:Not a Standard.

[Xest]

You have to look at why though.

For years browser vendors have done an utterly shit job of supporting the standards, they've just been hopeless at it, largely because they want to do things their way. Previously the W3C and it's members and contributors built the spec, these people were generally software engineers from companies like Nokia, Siemens, as well as from more desktop oriented companies, the browser manufacturers didn't hold the balance of power, they were given a spec that suited the people that actually build the web and aren't interested in platform specific bias. In contrast they wanted a web that suited them and their goals even though these often ran contrary to each other when really they should merely exist to display the web according to the spec designed by the more platform and content neutral developers.

Then came the rise of WHATWG, a group that basically represented the browser vendors and key technology players that long had vested interests, like the browser vendors, in ensuring the web goes the way they want- Apple wants it to work best for Apple's platform, Google wants it to be great at displaying ads whatever the platform and so on. They managed to wrestle away power from the more neutral committee at the W3C and they forced HTML5 onto the world.

The problem is of course, these companies haven't stopped being self-interested, and so what you get is rather than a spec designed to be generic and not specific to any single specific interests, you get a spec which has had everyone's individual interests lumped in as a big mangled mess, and suprise suprise, where interests collide, you get disagreement and refusal to budge. Look what a farce HTML5's video tag has turned out to be whereas in contrast the W3C historically where such issues came up simply specified the tag and was neutral to the format, which is why there are a number of image formats that work well on the web for different purposes and why formats such as PNG have been allowed to rise, the W3C let the market decide and letting the market decide has allowed things to adapt and change over time. This is the route the video tag appears to have been forced into anyway albeit in a much messier less explicit manner that doesn't look set to end well as unlike with images where all browsers implemented the popular market chosen formats, different browsers may well play different video to try and force theirs as the standard, a standard which may not be easily replaced without another HTML5 standards cluster fuck as it becomes outdated and obsolete.

The delay with HTML5 stems entirely from the reasons why WHATWG and HTML5 should never really have been allowed to hijack the web in the first place. Sure the W3C has got itself in on it now, but it knows it's merely there to try and cling on to what little power it has left, rather than the overall custodian of quality web oriented specifications. Letting the W3C lose it's prominent position of covering the views of many many companies to a handful powerful vested interests is probably the worst thing to happen to the web since Microsoft managed to get IE in a position go largely unchallenged for years with IE5 and IE6 causing many years of web stagnation.

Re:Not a Standard.

[Anonymous Coward]

Nope, that would be HTMM: HyperText Markup Mockup.

Re:Not a Standard.

[Lennie]

"HTML 5 is a major undertaking to rewrite how HTML works in a radically different way."

Actually it is the opposite. It does everything HTML4 does, without the rules everyone thought are stupid and already ignored. And includes a lot of things native which people where already doing through because browsers supported it but wasn't in the spec, javascript-workarounds, plugins, etc. Like HTML5-video people used plugins, now it is native. Like webcam-support, the HTML5-device-tag which isn't support by any browser yet allows that. It was already in Flash, now it will be 'native' to the browser, so you can import an image and manipulate it in javascript directly through the canvas-tag.

They are adding some other things as well, like WebGL.

Paving the cowpaths, baby ! :-)

Re:Not a Standard.

[billyswong]

When a spec/standard is not followed or even wilfully violated by major implementations, could we really see the spec as real? When the spec writers don't have content writers in mind, what good is being "neutral"? You mentioned Nokia and Siemens. See? They don't write webpages for a living. People don't rely on them to read webpages. They are out of touch to the WWW. Therefore they wasted all the time on XHTML, web engines produce a bunch of <p /> <br /> to their flavour, and browsers strip those slashes back out when interpreting.

IE were unchallenged for years because new competitors need to be compatible to webpages that relies on IE's out-of-spec behaviours. At least HTML5 promises there will not be any situations left unspecified.

Re:Not a Standard.

[Carewolf]

A HTML4 compliant browser would not be able to display any of the top-100 websites in the world. Most of them depend on a large number of bugs, and uses features that is incompatible with HTML4 if interpreted strictly (such as XHTML parsed as HTML 3, which is surprisingly common).

Re:Not a Standard.

[bored]

Part of the reason for the fast releases, is because previous versions of HTML were playing catch up with what was happening at the browser vendors and on the web. Back then, tags were being added left and right to the browsers to do things people wanted to be able to do.

no more numbers!

[shadowrat]

POST!

Re:no more numbers!

[The MAZZTer]

Because of a lack of numbers, my post is just as valuable as your post, regardless of the order of posting! So there!

Re:no more numbers!

[Anonymous Coward]

Because of a lack of numbers, my post is just as valuable as your post, regardless of the order of posting! So there!

Just as valuable, but infinitely less entertaining.

Re:no more numbers!

[Anonymous Coward]

Don't you get it? His post is XPOST 1.0!

Re:no more numbers!

[Anonymous Coward]

HTML A?

terrible idea

[godrik]

You'll get pages that becomes invalid with time despite they were valid before. That sounds like a very stupid idea.

Until you name the revision by dates, which is basically the same thing as giving version numbers...

Re:terrible idea

[hedwards]

That was my thought, it's tough enough to get browsers in compliance with a specific revision of HTML, now they're wanting to do away with numbering them?

I have to assume that this is an early April Fool's joke or the person suggesting it is full of it. But then again he works for Google and is probably just the sort of arrogant git that doesn't understand the implications of it for people that aren't constantly upgrading their browsers.

Re:terrible idea

[Anonymous Coward]

Until you name the revision by dates, which is basically the same thing as giving version numbers...

Or names! Firefox supports HTML Insomnia. IE is now on HTML Narcoleptic. Chrome upgrades to HTML Sonambulia. Opera is still on HTML Purgatory, but they will go to HTML Heaven next month. Oh, the possibilities!

Re:terrible idea

[Chris Mattern]

Numbers are so square. Introducing HTML version "Fred"!

Re:terrible idea

[vlueboy]

This is the same thing that happens with Operating Systems' need for versioning. What does the board plan, "reflexion" API's where each dev must ask the browser what it can do and assume the missing features in the ethereal standard are enough for the page to render 3 years from now? 10 years from now?

Just like an OS, the standard can drop features at any time; the point of numbers is to tell the dev from an easy test what stylesheets to junk and what error messages to give.

Re:terrible idea

[Dracos]

Validity rot isn't the issue here, it's that compliance is now a constantly moving target.

Browser vendors (some more than others) have always had a tough enough time getting their products to comply when the spec was finished and became static. With a dynamic spec chaos will surely ensue and developers will pay the price, because the lowest common denominator won't be as much of a known value as it is now.

Also, didn't Daniel Glazman lament a few years ago about how one of CSS's biggest flaws was the lack of version declarations built into the syntax?

I dare anyone to think of any other standards body that would dare pull a stunt like this. IEEE? ISO? I think not. Those bodies have an inherent respect for the standards they produce.

If anyone didn't think HTML5 wasn't a mess before, the stage is set now.

Has Tim Berners-Lee weighed in on this? Is he going to reign in these people?

Re:terrible idea

[msclrhd]

An upcoming revision will make HTML Multi-Freded.

Re:terrible idea

[Anonymous Coward]

You're too optimistic about naming. They'll actually be named things like "Hot Carl", "Rusty Trombone", and "Wolfbagging".

Remember, it's the internet. It's made of pervy cats.

Re:terrible idea

[scorp1us]

Its not as bad as you think.

We've moved everything to XHTML or XML for the most part. What is the worst that happens? You get an unsupported tag. In which case you can detect and handle the unsupported tag. HTML per se is on the way out. Encoding information as XML-style tags is here to stay.

Re:terrible idea

[Andy Dodd]

Yeah... This is a configuration management and interoperability nightmare.

I assume it's due to concerns that HTML revisions have come at intervals that are too long (Think Linux 2.4 to 2.6 - it took a LONG time and people considered it too long)- but dropping versioning completely is NOT the solution.

Changing the release schedule to involve smaller chunks per revision is more sensible. (See Linux development after the release of 2.6)

Re:terrible idea

[Jane Q. Public]

Even early HTML had, as part of its specification, the provision that you ignored tags you couldn't parse.

But this really is a terrible idea. This should be inherently obvious, given the difficulty that CURRENT browsers have had supporting the existing standards. Make the "standard" a moving target, and it will never happen.

It really does sound like a Microsoft move. Or a Homer Simpson move. I'm not sure which just yet.

Re:terrible idea

[pr0t0]

Theoretically, as long as all forward progress in HTML was always backward compatible and you never deprecated anything, it probably could be done. In practice, who knows. But that's really the problem because what happens when some new technology becomes available that, for whatever reason, is necessarily not backwards compatible? You just don't implement it? Even though it cures cancer right over the internet?

I think it's a worthwhile thought-experiment to imagine what kinds of technologies could benefit from an organic update methodology. There are probably more than a few that could. I'm not sold that HTML is one of them though.

Re:terrible idea

[hardburn]

They'll start naming them the way sequels get named.

• HTML: The Legend Continues
• HTML Unleashed
• HTML: The Next Generation
• HTML Reloaded
• Final HTML Fantasy XII-2

Re:terrible idea

[martin-boundary]

Sorry, that just doesn't scale.

If you have to parse the whole XML document just to find out that the last leaf you encounter is unsupported, then you've just done a lot of work for nothing. Put a version number at the start, and the parser can decide right away if it's worth attempting to decode the page or not.

What you're proposing is the kind of nonsense that ends up with everyone loading a DOM parser for every tiny little task just in case.

The fact that HTML5 is well formed XML doesn't mean that you should think of it as pure XML.

Re:terrible idea

[shutdown -p now]

So, will there be reboots and parallel uni... er, standards?

Re:terrible idea

[lennier]

* HTMLS

* HVF: HTML Vs Flash

* HTML Free With A Harder Vengeance

* The HTML Who Kissed Me

* HTML Rises

* HTML Episode Five: Attack of the Phantom Hope

* HTML: Turn Off The Web

and the inevitable retro-reboot, just called 'HTML'

Re:terrible idea

[TheRaven64]

The problem was that HTML was extended wrongly from the start. The img tag had an alt attribute, when this should have been in the cdata. If you'd had to write Goatse!, then this fallback would have worked. Instead, the first tag that was added to HTML after the initial version broke this compatibility (thanks Mosaic!). Oh, and the browser that introduced this abomination was later licensed by Microsoft and shipped under the brand Internet Explorer...

Re:terrible idea

[Anonymous Coward]

It's more likely that Google wants to push the web as fast as possible and follow a similar strategy as to Chrome, constant updates and that way they will push all other browsers manufacturers to follow suit or fall behind. . .

Re:terrible idea

[dakameleon]

* HTML Royale

* Quantum of HTML

* HTML Never Dies

* HTML Is Not Enough

* HTML Another Day

* From HTML With Love

* On HTML's Secret Service ... ok now I'm get just getting silly...

* Dr. HTML
* You Only HTML Twice
* HTML is Forever
* Live and Let HTML
* The Man with the Golden HTML
* For Your HTML Only
* A View to a HTML
* The Living HTML
* HTML to Kill

Re:terrible idea

[Anonymous Coward]

It just means you have to check every feature exists before using it which is good practice anyway.

Re:terrible idea

[Chris Mattern]

Actually, the reboot will be "HTML Begins"

Re:terrible idea

[Anonymous Coward]

Exactly right. It is just Google using its muscle to push for a change that's to its advantage. Same with its dropping support for that video codec. Microsoft = old boss, Google = new boss. Slashdotters need to wake up and meet the new boss.

Re:terrible idea

[yuhong]

XHTML2 was finally going to fix this. Fortunately XHTML requires even empty elements to be closed, which would allow fixing this in a way that is backward compatible with XHTML1. Unfortunately, IE9 is not even released yet, and IE8 and older don't support XHTML, forcing people to serve them as text/html. Fortunately, there is also the object element, and IE8 finally gained proper support for embedding images using the object element, and it allows proper fallback content.

Re:terrible idea

[yuhong]

BTW, Apple was going to make the same mistake with the canvas element too. Fortunately they fixed it early enough that the only pages that was using the old version was in Dashboard widgets.

Re:terrible idea

[Anonymous Coward]

They'll start naming them the way sequels get named.

• HTML: The Legend Continues
• HTML Unleashed
• HTML: The Next Generation
• HTML Reloaded
• Final HTML Fantasy XII-2

gorgious!

Re:terrible idea

[Anonymous Coward]

There will be also HTML Santorum.

Re:terrible idea

[sgbett]

HTML 0

Re:terrible idea

[Anonymous Coward]

LOL made my day :)

Re:terrible idea

[mrxak]

HTML Six Vegas 2

Wait... that has numbers, crap.

Re:terrible idea

[eugene ts wong]

That SRC attribute should have available for all elements. That being said, it would be nice to go back to a basic document. A standards body could test out the standards, and get a wide variety of input. As it is, P is used for phrases and paragraphs, but people still call all of them paragraphs. This really frustrates me, because I love HTML.

Re:terrible idea

[carmat71]

You'll get pages that becomes invalid with time despite they were valid before. That sounds like a very stupid idea.

Until you name the revision by dates, which is basically the same thing as giving version numbers...

Actually, to validate HTML 5, one would declare their doctype as: As opposed to previous versions where you would declare it as: As you can see, much shorter, easier to remember, and not dependent on future version, whether they contain numbers in the name or not.

Re:terrible idea

[Jane Q. Public]

Very well, but that still doesn't address the central issue here: whether scrapping version numbers is a good idea. I vote no. In fact I think it's a rather moronic idea, given the current state of compliance.

Re:terrible idea

[Anonymous Coward]

Ultra HTML x2 Quantum Lithium Extreme 2016.04.01
or HTML Transcending Maximum Legacy (HTML for short)

Re:terrible idea

[Anonymous Coward]

I have to assume that this is an early April Fool's joke or the person suggesting it is full of it. But then again he works for Google and is probably just the sort of arrogant svn that doesn't understand the implications of it for people that aren't constantly upgrading their browsers.

FTFY

Re:terrible idea

[ghmh]

It gets really interesting when they start doing the retrospective prequels.

+++ATH

Thanks google

[tokul]

Now we'll have beta quality software and beta quality standards. Another engineer brainwashed.

Re:Thanks google

[Anonymous Coward]

That's The Google Way, eternal beta.

Re:Thanks google

[Nadaka]

I know. At this point I would seriously consider junking the whole steaming pile and writing my own. Not that it would ever be used by anyone. The steaming pile has already reached critical mass.

Re:Thanks google

[morgan_greywolf]

Meh. Google's betas beat the hell out many others' released software in terms of stability and reliability. Chrome is certainly more stable the Firefox and IE, beta or no.

Re:Thanks google

[Skreems]

A. I call bullshit on the "more stable" claim, except for a few key architectural decisions that Firefox is implementing as we speak, and B. I call bullshit on the idea that they're entirely a Beta product. Their rendering engine is a solid, stable external system that has gone through many non-beta releases. If they didn't have an 8 year stable product as the core of Chrome, it wouldn't be nearly as high quality as it is.

Re:Thanks google

[TheRaven64]

That's how they ended up with XHTML 2. It's a really nice standard for semantically rich hypertext (although is likely to suffer severely from ontology drift, which is why representing ontologies is a huge project at the W3C). Unfortunately, it turned out that no one wanted an HTML version that was completely unlike any of the previous ones.

Re:Thanks google

[buchner.johannes]

Well it's better than eternal alpha.

Re:Thanks google

[Anonymous Coward]

That's The Google Way, eternal beta.

As opposed to having Grand Release Parties to celebrate the latest and greatest release of...what should rightfully be labelled "BETA"? Or never releasing a version that actually quite qualifies as "1.0"? Yeah. If you didn't notice, I'm off-topic. Then again, so are most of the rest of you. Am I from Google, so this is a Beta Comment? Microsoft, so I'll release several patches, hotfixes, service packs, and eventually an updated version of the comment? Or F/OSS, so this is really only version 0.000000000000000000000000000000...1? Let me know. I'm awfully confused about my place in the world.....

Re:Thanks google

[morgan_greywolf]

Their rendering engine is a solid, stable external system that has gone through many non-beta releases.

Except for the part about it being external, you could say the exact same thing for Firefox; Gecko is actually older than WebKit by quite a bit.

Re:Thanks google

[Anonymous Coward]

I miss so much the gamma level software and standards of the past! They had a great penetration on the markets.. Uh, that went wrong somehow in so many layers of .. material.

Re:Thanks google

[tokul]

Meh. Google's betas beat the hell out many others' released software in terms of stability and reliability. Chrome is certainly more stable the Firefox and IE, beta or no.

Standard is not software. It must be reviewed, have fixed have version number and documentation. You can't extend standard eternally and have new standard version every month.

Do you really think that software which silently puts three different entries in system task scheduler for update can be called stable. I would call such piece of shit a spyware. It acts like a spyware. Or Picasa faces feature which remains in listing even when it is turned off.

Without versions...

[MrEricSir]

...I can always render the latest HTML in Netscape Navigator. Right?

Re:Without versions...

[Khalil Fazal]

I don't get it.

Um...

[FatSean]

People will still need to differentiate between implementations of HTML that have different features...do they expect us all to just use the latest and hope nothing breaks?!

Re:Um...

[I8TheWorm]

Yeah, I look forward to the "this site is compliant with some of HTML standards and not others because they're too new. We can't really define that for you because there is no version, so best of luck to you" badges.

Re:Um...

[jgagnon]

It is possible that individual features of HTML will have versions instead of the entire standard. Maybe each tag will have a version? :P

Re:Um...

[RyuuzakiTetsuya]

Whee!

Time to break out those, "This page best viewed in..." badges again!

Re:Um...

[DragonWriter]

People will still need to differentiate between implementations of HTML that have different features...

This presumes that future versions of HTML from the point of adoption forward have backward-incompatible changes. The solution to that is to minimize backward-incompatible changes.

Re:Um...

[I8TheWorm]

It's still ok. I'll mail him a money order. Unfortunately it's for a higher amount, but he can just deposit it then send me the difference.

All will be well.

Re:Um...

[I8TheWorm]

And this is a classic example of having two replies open and responding in the wrong textbox.

I either need way more or way less Monster right now.

Re:Um...

[hitmark]

Or as time moves on, various tags, or sub-features of a tag, gets defined as deprecated.

As long as the basic definition of a tag, and its layout have some kind of default (hello, xml) then this can be done.

Re:Um...

[Anonymous Coward]

I think it's absolutely hilarious that nobody could tell the difference and modded you +5 insightful/funny anyway.

Re:Um...

[oatworm]

What kills me is that you somehow got a +5 Insightful mod out of that.

Slow Browsers

[Anonymous Coward]

Wow, so now my browser has to interrogate every single element on a page to determine what's supported BEFORE going to plugins etc.

Yikes...

Re:Slow Browsers

[Chris Pimlott]

As a practical matter, that's pretty much what you have to do now. Modernizr and the like make it easier for you, but ultimately that's what they're doing. You can't really trust what each browser claims to support anyway.

Re:Slow Browsers

[nschubach]

Just have the browser "not render" the element that's not supported anymore. That's pretty much what they do now.

Re:Slow Browsers

[Anonymous Coward]

Browsers already do this every single day.
A large chunk of websites either have none, or invalid doctypes, meaning your browser will have to go sip on some soup to figure out what the hell is even happening.

Re:Slow Browsers

[Anonymous Coward]

That's only the case if you don't use Google Chrome browser i think is the philosophy.

Re:Slow Browsers

[claytongulick]

It's not that big of a deal .

The js libraries (jquery, etc..) already deal with these differences between browsers, they'll just continue to take up the slack and we'll continue to be more dependent on them.

Translation

[dgatwood]

Microsoft got tired of people asking when they were going to fully support HTML 4....

Now everyone will be able to say "We support HTML" even though nobody fully supports all aspects of the spec. Just like today, only nobody will be able to point their finger at any sort of milestone that they missed, so companies that drag their heels in standards compliance end up looking better.

How is this a benefit again? It seems to me that we need smaller, more frequent milestones, not elimination of those milestones.

Re:Translation

[Anonymous Coward]

It is a benefit in the sense that it will terrorize people in using only the latest stuff coming from big companies because all the others will be playing catch up.

Oh you mean benefit for us? I dunno.

Re:Translation

[0racle]

This sounds more like a standards body getting sick of people and developers asking when HTML5 standardization would finally be finished.

Re:Translation

[M3.14]

They will actually introduce infinite number of very small milestones. That's why there will be no number - who would want versions like 5.333333333333 (ad infinum) ?

Re:Translation

[OnlyJedi]

Well, if the version numbering converged to something interesting like pi (or e, or the golden ratio) I could see people wanting it.
Then again, that kind of system wouldn't be rational.

Re:Translation

[jc42]

Now everyone will be able to say "We support HTML" even though nobody fully supports all aspects of the spec. Just like today, ...

Yeah, and the major benefit will be that developers of web sites will no longer waste their time trying to figure out what numbered version to declare in their DOCTYPE line, and pointing their fingers accusingly at browsers that don't support exactly that standard. They'll go right to testing against a flock of more-or-less current browsers (plus IE6 ;-), and making sure their HTML works somewhat sensibly in all of them.

Fact is, it has never worked very well to study any particular HTML standard and code strictly to that one. Since no browser actually implements that standard, we have always had to test against what passes for the real world, and tweak our HTML so it passes whatever test browsers the gang we're working with has decided to use.

One of my favorite counterexamples has been the ongoing attempts to persuade us to stop using the <center> tag, and replace it with CSS. It's funny to read the various suggested CSS "solutions" for this, then try them out against whatever browsers you've collected, and find that they don't work for some significant subset. Eventually you decide to just shrug and go with the center tag, which works (nearly) everywhere, and is syntactically simple. But lots of developer groups waste a lot of time fighting idiotic things like this, trying to follow some supposed expert's idea of the "right" way to do it, then finally giving up and just going with what seems to work (today).

The HTML "standards" are a mess, in large part due to the fact that the commercial browser developers see little reason to bother implementing even one numbered version correctly. This is helped along by management that has a motive to push for "walled gardens" (like IE6 ;-) that intentionally ignore or misinterpret part of the standards. This problem isn't going away. The best thing for HTML would be to face it, and work toward documenting what we might call a "real world standard" that is what most browser writers have deigned to implement. This would have to be replete with warnings about the unsolvable incompatibilities, and advice on either avoiding them or finding a workaround that at least displays semi-sensibly everywhere.

But that's probably beyond the purview of any official standards organization. After all, who would want to admit that the standard that you've worked so long at is being intentionally sabotaged by many or most of the commercial world? ;-)

Re:Translation

[msclrhd]

Then you have all the websites saying they are version XYZ, but are not valid against that version, or have some weird tag soup and expect it to work. A current issue is where Firefox renders some content bolder when using Win7 Direct2D if you have two bold styling attributes on a text section (e.g. GMail Apply button).

I've even seen some documents advertised as XHTML that don't parse as XML for a variety of reasons and are just HTML4 restyled as XHTML.

Re:Translation

[Nadaka]

Awesome idea, we called it XHTML2 before it was tossed in the garbage for a shiny new video tag and a canvas that re implements the qbasic drawing interface of the early 1980s.

Re:Translation

[Crudely_Indecent]

Or smaller, more manageable standards that inter operate.

Nobody can agree on the <video> tag, so remove it and make it a separate standard.

How many layers of the HTML5 onion need to be peeled before the a consensus can be reached?

Re:Translation

[Anonymous Coward]

You have never heard about the "separate content from presentation" principle, right?

There is a very good reason to apply it when you work with documents. That's why the standards define HTML and CSS.

On the other hand, developers don't understand this principle. They don't think much why the standard has been created this way, they think mainly about their code. Dude, what's this stupid CSS things that requires so much coding, let's just support , it's so simple ... I suppose this is typical among developers, and that's why browsers don't support standards very well.

Re:Translation

[martin-boundary]

The HTML "standards" are a mess, in large part due to the fact that the commercial browser developers see little reason to bother implementing even one numbered version correctly.

How's 1999 working out for you?

Except for IE, the most popular modern browsers are based on open source engines, which have spent the last 10 years working to get the standards right. And aside from Opera and Microsoft, all major commercial browsers are based on those open source engines.

Re:Translation

[shutdown -p now]

Microsoft got tired of people asking when they were going to fully support HTML 4....

Now everyone will be able to say "We support HTML"

This announcement comes from WHATWG, not from W3C HTML WG. And you know the difference between the two? Microsoft is not in WHATWG.

Re:Translation

[TheRaven64]

The correct solution to this would be to just release HTML 5 in a timely fashion. There are a lot of bits of HTML5 that are now finalised and have the requisite 2 or more independent implementations. They should move these into a new standard and call it HTML 5. All of the stuff that's experimental in the current HTML5 draft then goes into HTML 6. No more moving targets. Instead, they have a 'living standard' HTML 5, where you're told 'you can use this bit, it's stable, but not this other bit here'.

Re:Translation

[TheRaven64]

a canvas that re implements the qbasic drawing interface of the early 1980s

No it doesn't. It implements the PostScript drawing model. Each method on the canvas corresponds exactly to a PostScript or PDF drawing command.

Re:Translation

[KingMotley]

Well except they are all buggy, and take forever to actually fix the bugs when you submit them. Firefox has bugs that go back over 6 years. I personally have registered bugs with all 3 chrome, safari, and firefox. Some of them over a year old, and NONE of them have been fixed.

Re:Translation

[aiht]

Well, if the version numbering converged to something interesting like pi (or e, or the golden ratio) I could see people wanting it. Then again, that kind of system wouldn't be rational.

Ha. Ha. Ha.
*claps*

Re:Translation

[maxwell demon]

Well, if the version numbering converged to something interesting like pi (or e, or the golden ratio) I could see people wanting it.

Then again, that kind of system wouldn't be rational.

But it's real!

Re:Translation

[Anonymous Coward]

You mean as the version numbering system for TeX and LaTeX ?

Re:Translation

[rmo6]

Microsoft got tired of people asking when they were going to fully support HTML 4...

Except replace Microsoft with Google and replace HTML 4 with "we're going to support what we want, when we want and not have to comply to any one set of stringent rules". It helps to RTFA instead of rehashing the same old about the futility of IE's standards compliance.

Living Standard?

[ultranova]

So, in the future it's impossible to figure out what browser supports what? Because, after all, browser support is dragging behind years even now. Or is that the very goal of Google? Make Chrome the de facto standard, and force everyone else to play the catch-up game?

Seriously, don't do this "living standard" crap. At the very least use minor version numbers to identify a given set of standards. Don't force me to guestimate how a web page I write today is going to behave in browsers 5 years from now; let me specify what behaviour I want.

Re:Living Standard?

[jc42]

So, in the future it's impossible to figure out what browser supports what?

Why would you expect the future to be different from the past?

Re:Living Standard?

[DragonWriter]

Don't force me to guestimate how a web page I write today is going to behave in browsers 5 years from now

The problem this addresses is that, because the standards in fact are evolving now, the public snapshots are usually treated as out-of-date but the browser vendors and other major players, so coding to the publicized snapshots itself doesn't provide the most reliable method of assuring behavior today, much less 5 years from now.

Re:Living Standard?

[morgan_greywolf]

Make Chrome the de facto standard, and force everyone else to play the catch-up game?

You will be assimilated. Resistence is futile.

Re:Living Standard?

[Daniel Phillips]

Where they write "living" I read "nebulous".

Re:Living Standard?

[IICV]

Seriously, don't do this "living standard" crap. At the very least use minor version numbers to identify a given set of standards. Don't force me to guestimate how a web page I write today is going to behave in browsers 5 years from now; let me specify what behaviour I want.

So which do you want right now: the way IE 9 interprets HTML5, the way Chrome interprets HTML5, the way Firefox interprets HTML5, or the way Opera interprets HTML5? They're all slightly different, after all.

Oh and how exactly do you specify that in an HTML document? Is that the purpose of those silly little "Viewed best with Internet Explorer" badges?

Re:Living Standard?

[Daniel Phillips]

Instead of doing this stupid thing a mechanism similar to OpenGL extensions would make far more sense. It has worked well for OpenGL, allowing vendors to innovate while providing application programmers a clear definition of what facilities are/are not available on a given platform. Yes, it requires the application programmer to implement fallbacks in some cases but this is not worse than the html situation today.

It is really, really important to be able to evaluate objectively the degree to which a browser implements html standards. This new brain addled flight of fancy flies in the face of that.

Re:Living Standard?

[BZ]

If you specify that your page is HTML 2.0 and serve it up as text/html, not a single modern browser will render it per the HTML 2.0 spec text (such as that is).

So you've never been able to "specify what behavior I want". This story (about something Ian said years ago, note) is just about the fact that the HTML spec editor would like to stop pretending otherwise and clearly describe what's actually happening as opposed to what some would really like pretend should happen...

Re:Living Standard?

[theaveng]

browser support is dragging behind years even now. Or is that the very goal of Google? Make Chrome the de facto standard, and force everyone else to play the catch-up game?

Sounds like Netscape circa 1995. They kept adopting new tags (blink) and features (ex: frames) to push forward and let everyone else catch up.

IE was doing the same thing around 1998, with their introductions of new features that other browsers couldn't render.

Now Google's doing it.
Bad google.
Bad

Re:Living Standard?

[ultranova]

If you specify that your page is HTML 2.0 and serve it up as text/html, not a single modern browser will render it per the HTML 2.0 spec text (such as that is).

But they will know what I meant. That's the key here - to allow the browsers know what I the Web Page Maker was trying to say, rather than try to guess. That is why version numbers are necessary.

Re:Living Standard?

[ultranova]

he problem this addresses is that, because the standards in fact are evolving now, the public snapshots are usually treated as out-of-date but the browser vendors and other major players, so coding to the publicized snapshots itself doesn't provide the most reliable method of assuring behavior today, much less 5 years from now.

All of that is true. And none of that chances the fact that it makes sense to declare how you want a particular document to be interpreted. I understand that the browsers 10 years from now might not be able to interpret current web pages properly; but I'd rather they at the very least had the option of doing that, by reading the HTML version number and doing their best effort translation.

Re:Living Standard?

[BZ]

Except in practice, web authors _don't_ mean it when they write a doctype, so browsers assume that they should ignore it anyway and guess (or rather render per the latest version of HTML they support). So in practice, version-numbering your HTML is just playing pretend.

There are also philosophical reasons for not having a versioned HTML; I'm happy to describe those if you're interested.

Re:Living Standard?

[ultranova]

Except in practice, web authors _don't_ mean it when they write a doctype, so browsers assume that they should ignore it anyway and guess (or rather render per the latest version of HTML they support). So in practice, version-numbering your HTML is just playing pretend.

No, browsers don't do that; rather, they use the doctype - which includes the HTML version number - to figure out how to render the page. Google "quirks mode" for details.

There are also philosophical reasons for not having a versioned HTML; I'm happy to describe those if you're interested.

Let's hear them.

Re:Living Standard?

[BZ]

Browsers do have a quirks mode, but it's not really based on HTML version. It's based on a heuristic, which buckets some HTML4 doctypes into quirks mode and others into standards mode.

Browsers also have no plans to add any more mode switches (except for MSIE, of course), so adding more versioning information isn't exactly useful in that regard.

> Let's hear them.

I was going to summarize, but just found the link to the original post that sums up the argument. See http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html

Note that that's where we are right now with IE; IE8 ships with at least two different layout engines (like separate codebases, last I checked) to handle "IE5" mode and "IE7" mode. And the new "IE8 standards" mode it has is implemented as a set of changes to the IE7 engine, I _think_.

Now Microsoft is OK with this: they have near-unlimited manpower (e.g. for IE9 their JS team is about 25% of the number of total engineers working at Mozilla) and don't have to worry about download size or size of testing matrix (thousands of test systems available easily) or silly things like that.

But forcing this sort of complexity on new market entrants will just entrench the existing players and be bad for the web. We _want_ people to create new web browsers!

Re:Living Standard?

[ultranova]

But forcing this sort of complexity on new market entrants will just entrench the existing players and be bad for the web.

The complexity is already there. As you noted yourself, browsers already implement multiple rendering modes/engines based on what they detect the content to be. Version numbers simply allows this to work simply and reliably, thus removing the need for any new browsers to implement complex heuristics to guess what to do with the content.

It's not like a browser has to respect the version number, it simply makes it possible to behave correctly.

We _want_ people to create new web browsers!

Why? Does it really serve anyone's interests to have multiple almost-but-not-quite-compatible HTML renderers / Javascript virtual machines? All it does is make the lowest common denominator even lower, and force developers to use massive compatibility libraries to deal with the incompatibilities and missing features. And lack of version numbers is going to make things even worse by adding another source of ambiguity.

Re:Living Standard?

[BZ]

> The complexity is already there

No, not at the level you get if you start making incompatible changes. Quirks vs standards mode is a tiny set of well-contained changes in non-IE browsers.

> It's not like a browser has to respect the version number

If the number doesn't have to be respected to get proper functioning, why is it needed at all?

> Does it really serve anyone's interests to have multiple almost-but-not-quite-compatible
> HTML renderers

Yes. It has several major benefits:

1) It creates competition, forcing the existing implementations to improve.
2) It allows users of minority platforms (new platforms, say) to create a web browser on
        their platform as needed. Right now, the major JS engines only work reasonably on
        x86/x86-64/ARM. We want it to be simple to get a browser running on a new hardware
        architecture as needed. Unless you think that x86-64 and ARM are all we will need,
        forever.

On a more serious note, we've already had the web in a state where there was only one browser around. That browser was IE6. Are you seriously advocating that this was a _good_ state?

> And lack of version numbers is going to make things even worse by adding another source
> of ambiguity.

The main effect of lack of version numbers is that the people evolving the standards will have to actually think about the changes they make as opposed to pretending that changing the version number allows you to make arbitrary changes. See also XHTML2.

Problem

[Improv]

There will be no way to pressure browser developers to be compliant with "NGHTML 4.7" if we can't even talk about it because it lacks a name. It'll also be hard to enumerate features of releases, to decide what version of the standard we're talking about and have programmatic support for that, etc.

This eliminates most of the benefits of having standards to begin with.

Re:Problem

[FauxPasIII]

"Don't you see that the whole aim of Newspeak is to narrow the range of thought? In the end we shall make thoughtcrime literally impossible, because there will be no words in which to express it."

http://www.george-orwell.org/1984/4.html

Re:Problem

[Anonymous Coward]

There will be no way to pressure browser developers to be compliant with "NGHTML 4.7" if we can't even talk about it because it lacks a name.

It's all about inflection.

For example, Firefox supports HTML, but not HTML or HTML.

Re:Problem

[maxume]

It's not like 'supports html4 and css2 and xhtml' has ever actually been particularly true, web developers already have to choose which features to use and which ones not to use.

Re:Problem

[msclrhd]

I'm sorry, I don't speak either italic or bold! Do you speak small caps?

Irrelevant information about irrelevant topic.

[Anonymous Coward]

Version numbers are irrelevant because HTML is irrelevant to designers.
What matter are the relative version numbers of Dreamweaver, Firefox and IE.

And before someone tries to say, "yes, it'll matter because the back end is still HTML,"
NO, it won't matter, any more than internal guidelines for software design matter at
any particular company. And despite management statements to the contrary, they
truly don't matter even there, within the industry.

And yes, I'm insensitive. Grow a pair.

Re:Irrelevant information about irrelevant topic.

[Panaflex]

yes, it'll matter because the back end is still HTML. And not everything that creates and renders HTML is dreamweaver, firefox or iexplorer. And while management practices do not matter, specifications and implementations DO matter. Most especially, for those that rely on accuracy. product comparisons, and compatibility.

Re:Irrelevant information about irrelevant topic.

[Anonymous Coward]

And not everything that creates and renders HTML is dreamweaver, firefox or iexplorer.

And they are irrelevant. IE & Firefox alone hold 74% of the browser share. Throw in Chrome and you have 86%. Pretty much anything else is safe to ignore and worthless to most people.

Re:Irrelevant information about irrelevant topic.

[Cinder6]

It'll matter to web browsers, which will have to spend a lot more effort trying to figure out exactly how a page is supposed to be displayed, without version numbers.

Re:Irrelevant information about irrelevant topic.

[h4rr4r]

Ignoring 14% of your customers is a pretty stupid move.

Re:Irrelevant information about irrelevant topic.

[Anonymous Coward]

So, you're happy losing 14 visitors out of every 100 you would otherwise have had if you had not ignored the 14% of people using Safari, Opera, and the various other small browsers out there? Granted, 14 of 100 doesn't sound bad, until you scale it up and realize that you are giving up 14k of every 100k visitors. If even 10% of those 14k spent 50$, you're leaving 70k$ on the table just from those people. Now, consider that those people will scare off anyone else they know if your site comes up in conversation and the damage multiplies.

Your attitude is rather like saying you're going to ignore the blind because most of your visitors have sight. So fuck 'em because they're blind. This conveniently ignores the fact that some people will avoid doing business with companies that don't make at least a minimal effort to make reasonable accommodations for handicapped individuals. So, if 14% of your potential customer base is blind and you choose to ignore them, you can rest assured you will lose business from more than those 14% of your potential customer base.

Way to cut your nose to spite your face!

Re:Irrelevant information about irrelevant topic.

[Anonymous Coward]

You wrongly presume that the people in that 14% ARE potential customers. When on realizes that one hardly gets any customers from Safari or Opera the choice is pretty much easy to make. They don't matter.

Re:Irrelevant information about irrelevant topic.

[FictionPimp]

maybe there is a reason you don't get customers from those browsers.

like the page doesn't fucking work!

Re:Irrelevant information about irrelevant topic.

[Anonymous Coward]

You're still an idiot. I use Opera exclusively, except for the instances where I must get something done AND the site will not allow me to use Opera AND I don't have an alternative supplier of the service or product. Otherwise, if a site doesn't work in Opera, I find another source/site to accomplish my goals. I have Chrome, Firefox, and Konqueror available (in Linux) and Chrome, Firefox, Safari, and Internet Explorer (in Windows), but if you don't want my business as an Opera user, I'll be happy not to use your services or purchase your product. Why should I fire up another browser just to buy from you when supporting Safari and Opera is pretty much dead easy?

The sites I develop get tested in all my available browsers and until it reaches a point where I find the display acceptable in each of those, then I'm not done working on the site. If my boss finds something unacceptably broken or screwy in any browser, it gets sent back to me to fix it asap. In my experience, the display is remarkably uniform between Opera, Firefox, and Safari, with generally only minor differences between the three. So, from my perspective, not supporting at least Opera and Safari is supreme laziness on your part, which is why I won't be bothered to fire up a different browser to do business with you.

Re:Irrelevant information about irrelevant topic.

[Panaflex]

Howard Moskowitz - Spaghetti Sauce!

Re:Irrelevant information about irrelevant topic.

[rudy_wayne]

So, you're happy losing 14 visitors out of every 100 you would otherwise have had if you had not ignored the 14% of people using Safari, Opera, and the various other small browsers out there? Granted, 14 of 100 doesn't sound bad, until you scale it up and realize that you are giving up 14k of every 100k visitors. If even 10% of those 14k spent 50$, you're leaving 70k$ on the table just from those people.

That's a completely phoney argument, and it's pretty much the same exact claim the RIAA/MPAA/BSA makes when they say they are losing gazillions of dollars. You can't "lose" something you never had in the first place.

Re:Irrelevant information about irrelevant topic.

[nschubach]

Honestly... how many browsers do that?

I can think of one. IE with their doctype hacks to determine what rendering mode to put it in.

Otherwise, the other browsers render the pages (new or old) in pretty much the standard way that new pages are rendered.

Re:Irrelevant information about irrelevant topic.

[DragonWriter]

It'll matter to web browsers, which will have to spend a lot more effort trying to figure out exactly how a page is supposed to be displayed, without version numbers.

Why would they need to do that?

Re:Irrelevant information about irrelevant topic.

[msclrhd]

Disabled users? Does your site work using lynx? Can it be used through a screen reader/assistive technologies?

Re:Irrelevant information about irrelevant topic.

[Crudely_Indecent]

I spend more time testing with Safari and Opera than other browsers because I would rather spend less time supporting my users who use Safari and Opera.

Re:Irrelevant information about irrelevant topic.

[Anonymous Coward]

I use Opera exclusively

Good job. Want a cookie for using a browser that is irrelevant to the business world?

Re:Irrelevant information about irrelevant topic.

[HarrySquatter]

If a web browser is tying it's rendering strictly to a version number it is mega fail.

Re:Irrelevant information about irrelevant topic.

[Anonymous Coward]

You wrongly presume that the people in that 14% ARE potential customers.

Are you trolling?

Fair enough perhaps that you make the distinction between potential customers and actual customers, but you're still thinking about it backwards: "What percentage of users of these browsers are potential customers?". What you should be thinking is, "what percentage of my potential customers are using these browsers?", which, unless you're selling IE/Firefox/Chrome specific browser plugins, is 14%. If not all of those 14% of potential customers become actual customers, that's fine, but you can't ignore the fact that they are all potential customers.

When on[sic] realizes that one hardly gets any customers from Safari or Opera the choice is pretty much easy to make. They don't matter.

Emphasis mine. "Hardly gets any" implies that the percentage of your actual customers using those browsers is greater than zero. If you can really afford to ignore your customers and choose to treat them as if they are "irrelevant" and "don't matter" based on the browser they use then please let us all know what you're selling? Sounds like a pretty sweet deal. Is it Monster Cables?

Re:Irrelevant information about irrelevant topic.

[Cinder6]

Thinking about it now, you (and the other posters after you) are right; it isn't a big deal. I was thinking that, since the doc type tag exists, it was actually used by browsers. So, I'll eat crow and say I was wrong.

Re:Irrelevant information about irrelevant topic.

[KingMotley]

You are correct, most browsers DO use the doctype, and any web designer that's written html for more than a week knows this.

So instead...

[DoofusOfDeath]

So instead of versions, we'll have a big vector of flags, where each flag indicates whether or not a particular HTML feature is required, supported, etc.? And a given web page will work with a given browser only if their two flag vectors are compatible?

This is stupid. Standards exist for a reason.

Re:So instead...

[mini me]

We'll have exactly what we have now. Browser vendors were already adding draft features into their product before the specification was finalized. Just look at how many browsers support HTML5 features, even though HTML5 does not exist as a standard yet.

Re:So instead...

[Just Some Guy]

we'll have a big vector of flags

No. There will be a /htmlcaps.xml in the root of every website, enumerating the features necessary to render it.

Re:So instead...

[Anonymous Coward]

And it will be 6.2MB in size.

Re:So instead...

[Qhartb]

This page is best viewed in browsers supporting HTML0xCFF7 and better.

Re:So instead...

[owlstead]

I was going to mod, but I cannot let this pass. Browsers have always added features that's true. And in some ways it is required, you cannot make progress by mindlessly adding to the standard, you will have to try out new features first.

But any *mainstream* site should be able to choose a HTML version to support, maybe taking into account some features that are badly supported by the browsers. This way you can be reasonably sure that most browsers (and with the internet appliances market soaring, there are many important ones) will parse & display the page as intended.

Now if you remove this idea of a base set of features, which is captured in the version number, you are left with checking each and every device. There are already too many choices within most standards - the more choices of differentiation, the more bugs and incompatibilities.

I'm involved in some international standardization, and it's mind-boggling how many unneeded choices are added to standards in the name of technology, flexibility and - of course - politics. Each and everyone adds to at least another branch in source code to test. Some choices are so uncommon that they are never really tested at all (and you can imagine what happens if they are encountered).

Re:So instead...

[HereIAmJH]

Browser vendors were already adding draft features into their product before the specification was finalized.

Browsers adding draft features isn't a problem. Nobody cares that a browser supports a feature that nobody uses. Developers adding draft features to web sites is the problem.

Re:So instead...

[parlancex]

I think it's ironic to hear this kind of moaning from the open source community when OpenGL developers have had to deal with the similar mish-mash of supported features and no standard problems and DirectX developers have always been able to rely on standard feature sets built into major version numbers of the API.

Linked blog article is fluff with no insight

[Anonymous Coward]

Go straight to the source instead.

Re:Linked blog article is fluff with no insight

[franciscohs]

It's interesting how around there are all praises, and around here are all rants. I wonder why's that... (I'm with the latter group, obviously)

Re:Linked blog article is fluff with no insight

[Anonymous Coward]

Indeed, and as that article points out, this change in naming applies ONLY to what the WhatWG was calling "HTML5", not to be confused with what W3C calls "HTML 5." For anyone that's been following this, or has read Zeldman's HTML5 book, knows, "HTML5" and "HTML 5" can refer to entirely different sets of standards.

The W3C, as far as I can tell, is still taking "snapshots" of WhatWG's "HTML" spec and numbering them, and the W3C is still the primary authority when it comes to official web specifications.

This change really isn't as big of a deal as people here seem to think, and the original article does confuse the issue.

Re:Linked blog article is fluff with no insight

[The Moof]

I'm guessing we've all had a project killed by feature creep, and they haven't. Essentially, that's what they're proposing: a spec with features constantly in flux without any milestones to aim for.

Re:Linked blog article is fluff with no insight

[icebraining]

It's interesting how around there are all praises

Yes. Especially comments like 14, 17, 18, 19, 20, 26, 32, 36 and more. All praises.

Just like Chrome?

[Anonymous Coward]

Do they mean the browser Chrome? As in Google Chrome 8.0.552.237?
Is 8.0.552.237 not the version?

Re:Just like Chrome?

[ElectricTurtle]

It is for n00bz like you, I'm running 9.0.597.47 beta.

Re:Just like Chrome?

[Bill_the_Engineer]

You're still out of date. I have the latest bleeding edge version of chrome. I'm running Chrome: living standard edition.

Re:Just like Chrome?

[igreaterthanu]

It is for n00bz like you, I'm running 9.0.597.47 beta.

What a n00b, I'm running 10.0.634.0 dev

I can finally paste into Slashdot comments. The future is wonderful.

Re:Just like Chrome?

[dn15]

Do they mean the browser Chrome? As in Google Chrome 8.0.552.237?
Is 8.0.552.237 not the version?

I was going to comment on just the same thing. I fail to see how Chrome's approach compares to not having a version number at all. Maybe the logic is that Chrome changes its major version number 3 or 4 times a year, rendering it meaningless to the end user? :)

Re:Just like Chrome?

[Cl1mh4224rd]

Do they mean the browser Chrome? As in Google Chrome 8.0.552.237?
Is 8.0.552.237 not the version?

I wonder how the Google Chrome developers would enjoy bug reports without version numbers.

Re:Just like Chrome?

[Anonymous Coward]

What a n00b3r, I'm running 10.0.644.0 canary build

Re:Just like Chrome?

[syousef]

You're still out of date. I have the latest bleeding edge version of chrome. I'm running Chrome: living standard edition.

I thought it was "Chrome: In Living Color Edition" where the splash screen is a young Jim Carey who gesticulates wildly as he imitates Kirk. This will be followed by Chrome: Saturday Night Live edition.

Re:Just like Chrome?

[Anonymous Coward]

I personally prefer Chrome: It's alive (and it pastes too in /.)! version. I might come back to /. to read any answer to this post if the browser lets me. Maybe if I ask really nic

Re:Just like Chrome?

[Anonymous Coward]

No, that's the IP address of your machine. It gets reported to Google every time you click on "About Chrome."

Re:Just like Chrome?

[maxwell demon]

"I've found a bug in the browser."
"OK. Let's first identify which browser version you have."
"Well, I can''t find a version number."
"There isn't one. However we can identify the build by making some tests."
"What tests?"
"Well, let's start. Please open the about dialog, and then give us the exact RGB values of the background. Those changed recently, which allows us to restrict the range where to look. Also, we need the exact space between "Google" and "Inc" in Pixels, and your screen resolution and size, so we can find out which tweak of the font rendering engine is in use, which allows to further narrow it down." ...

Internet/server backed "Apps" are the web 3.0

[whiteboy86]

HTML5 is lacking in adoption, incompatible, slow etc.

And there is no need to further develop a bi-plane when you fly a jet already.

Re:Internet/server backed "Apps" are the web 3.0

[jimmerz28]

Really? That's weird because I thought browsers were waring over who could get HTML 5 features out first, who had the most, and showing them off.

But I might be totally crazy.

Re:Internet/server backed "Apps" are the web 3.0

[MightyMartian]

And what is this jet you speak of? Javascript, CSS, DOM? If these are jets, then someone put the turbines in backwards, pasted the wings on with glue sticks, and is using banana peels as fuel.

Re:Internet/server backed "Apps" are the web 3.0

[diamondmagic]

...The various Javascript APIs, web sockets, IndexedDB, SVG, etc, are not HTML 5.

Re:Internet/server backed "Apps" are the web 3.0

[hedwards]

It's a typical problem, the browsers battle it out first, then applications and sites tend to pop up. Which makes it a bit awkward at times.

From what I can tell, they're opting to keep the aspect of HTML which is more or less the most broken under the justification that they've always done it that way, regardless of the fact that HTML5 was mostly supposed to be changing that. A new set of standards that both modernized and theoretically was implemented by all the browsers.

It's more or less inevitable that what's going to end up happening is a rehash of the Netscape versus IE battle of the 90s and a return to fragmentation. It might not be intentional, but if the standards keep changing it's going to be a real challenge actually cruising the web.

Re:Internet/server backed "Apps" are the web 3.0

[ThatMegathronDude]

Well, yeah. Those features came first, then standards came behind to try to reduce the amount of extra work necessary to work around browswer weirdness.

Re:Internet/server backed "Apps" are the web 3.0

[jimmerz28]

I never said they were...but the HTML APIs that allow the implementation of those things surely are part of the recommendation:

http://www.w3.org/TR/html5-diff/#apis

As well as the elements like , , and the semantic ones such as , , .

http://dev.w3.org/html5/spec/Overview.html

Re:Internet/server backed "Apps" are the web 3.0

[Anonymous Coward]

Incorrect. There can't be a web 3.0 because there was never a 2.0, or a 1.0. The version system people apply to the web is bullshit, plain and simple.

Buzzword don't change that.

Re:Internet/server backed "Apps" are the web 3.0

[definate]

Dear Sir,

I am an investor in green energy, particularly with regards to the airline industry.

I am interested in your design for a backward turbined banana peel fueled engines, or as we in the industry call them BTBP engines.

Please get in contact with me, as we are very interested, and may also like to subscribe to your magazine.

Sincerely,

Def Inate Industries

Re:Internet/server backed "Apps" are the web 3.0

[gblues]

Where we're going, we don't need standards.

Re:Internet/server backed "Apps" are the web 3.0

[billyswong]

Nothing prevent a jet to be also a bi-plane.

Finally

[guybrush3pwood]

This wins the Best Non-News Prize of this week.

Chrome has version numbers

[commodore64_love]

I'm running chromium 7 right now.

Shield

[jimmerz28]

I like the shield logo, it fits the whole Web 2.0 of bold and simplistic.

Reminds me of cell shading and Zelda: The Wind Waker for some reason.

Re:Shield

[nschubach]

It's really ironic that the logo is not in SVG though. Isn't it?

Re:Shield

[jimmerz28]

I'm assuming since mostly everyone is still in IE 8 they wanted them to be able to see it. You can download all the images in both SVG & PNG format, which I like!

Huh?

[gstoddart]

Since when did Google become the keepers of the HTML spec?

I think a randomly changing feature-set sounds like a bad idea. HTML is supposed to be a standard, not something which just changes without any real control behind that.

This is like agile programming run amok -- let's expect the customer to have to upgrade to the latest nightly build. That'll work!

Re:Huh?

[HarrySquatter]

Since when did Google become the keepers of the HTML spec?

Since Ian Hickson moved to Google?

Re:Huh?

[hedwards]

It's Stockholm syndrome. They're so used to the unreliable renderings that they're needing to create something which keeps that aspect of cruising the web.

Re:Huh?

[mini me]

Browsers were already adding support for draft features as they happened. I believe his point is that there is no use in waiting until the spec is finalized; add the features they become available and let people start using them now.

Re:Huh?

[Anonymous Coward]

And Google shows us yet again that if you want to do something which makes perfect sense to an autistic 12 year old, gives no thought to real-world consequences, and actively torpedoes practicality, give it to Hickson. Sigh.

Re:Huh?

[DragonWriter]

Since when did Google become the keepers of the HTML spec?

Google is not "the keepers of the HTML spec". Ian Hickson, who happens to work for Google, is the editor of the HTML5 spec. Usually, spec maintainers work for a firm involved in the area the spec addresses.

I think a randomly changing feature-set sounds like a bad idea.

In none of the discussion of this change has there been any indication that the WHATWG process for HTML will involve random changes.

HTML is supposed to be a standard, not something which just changes without any real control behind that.

There is a process, which is discussed in the WHATWG FAQ. The process just doesn't involve version numbers anymore.

Re:Huh?

[Anonymous Coward]

Or, as marketing folks like to say, "we want to be -ahead- of the curve". Nevermind that 30-40% of your audience won't have a good experience. The typical response being, "we want to be seen as cutting edge". Arguing with them is like shitting into a fan.

I'm so tired of 'analysts' who goto tech sites - and somehow think that they're qualified to make technical decisions, yet they have no real-world experience - or vision, for that matter.

The typical response being, "HTML5 is the roxxor - everyone is talking about it!".

Re:Huh?

[xenapan]

In other Google news: Chrome works off the cloud, HTML specs follow.

Re:Huh?

[msclrhd]

Version numbers? Where we are going, we don't *need* version numbers!

Re:Huh?

[smellotron]

In none of the discussion of this change has there been any indication that the WHATWG process for HTML will involve random changes.

OTOH, it might make the web more interesting if the WHATWG adopts a more Gygaxian approach to standards development.

Re:Huh?

[Anonymous Coward]

The idea is that everyone uses Chrome, which updates automatically. No more worrying about whether the customer has an updated browser!

Have to distinguish somehow!

[adosch]

IMHO, I think it's probably not a great move to go version-less, because there are some night-and-day differences between HTML preceding HTML5. I can see web 2.0 development and browser test support getting a bit messy going this route. But W3C they W3C said so. Whatever. I'm sure they'll spend much more time waffling over the logo than having any more version number discussions...

Re:Have to distinguish somehow!

[cjcela]

Maybe HTML will die on its own, on the hands of incompetency. Then hopefully a reasonable standard will arise. One that is not designed by committee.

Re:Have to distinguish somehow!

[Anonymous Coward]

Have to distinguish somehow!

So please distinguish. The W3C didn't say so. Mr Hickson said so, under the pseudonym of "WHATWG". He also says that now that his new pseudonym is "HTML" there's no need for a defined process because he's the sole decider anyway:

2. 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

We = pluralis majestatis

That link gives it away ...

[rjmx]

The subheading on that link seems particularly appropriate:

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

Sigh.

Idiocracy

[diemuzi]

Idiocracy is upon us!

Re:Idiocracy

[denis-The-menace]

I wish they would create a mashup of Idiocracy and 1984.
Oh wait, I'm living in it.

Horrible Idea....

[Anonymous Coward]

This is posibly one of the worst ideas I have ever heard. Pages will ecome invalid at a steady rate and browsers will become prey to extreme amounts of tedious updates. A standard such as HTML asolutely NEEDS to be worked on in a system which uses version numbers as opposed to the "living" idea.

Their justification FAQ:

[Anonymous Coward]

Their justifications for the decision are here:

http://wiki.whatwg.org/wiki/FAQ#What_does_.22Living_Standard.22_mean.3F

Re:Their justification FAQ:

[cowboy76Spain]

From the page

Despite the continuous maintenance, or maybe we should say as part of the continuing maintenance, a significant effort is placed on getting the specifications and the implementations to converge — the parts of the specification that are mature and stable are not changed willy nilly. 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. Instead, we now make sure to update the specifications to be detailed enough that all the implementations (not just browsers, of course) can do the same thing.

TRANSLATION: As we are incapable of agreeing in an standard, we will wait what becomes a de facto standard en then we will call it "the standard". Way easier, boys.

In practice, implementations all followed the latest specs draft anyway, not the latest snapshots. The problem with following a snapshot is that you end up following something that is known to be wrong. That's obviously not the way to get interoperability! This has in fact been a real problem at the W3C, where mistakes are found and fixed in the editors' drafts of specifications, but implementors who aren't fully engaged in the process go and implement obsolete snapshots instead, including those bugs, without realising the problems, and resulting in differences between the browsers.

TRANSLATION: We hoped that developers would wait for centuries until we sorted our mess out, but, oh surprise!, they didn't wait for us and were following our proposal to close for our comfort. Now that is solved as we can let them lead and do our work in our place, to the benefit of the strongest player...

Re:Their justification FAQ:

[Anonymous Coward]

Where what's emerging as and expected to be the strongest player is... Google.

it just seems appropriate

[Anonymous Coward]

GET!

Re:it just seems appropriate

[gorzek]

REST!

Re:it just seems appropriate

[Anonymous Coward]

POST ACTION="/dev/null"

Re:it just seems appropriate

[Canazza]

SOAP!

Re:it just seems appropriate

[ManuelH]

XMLHttpRequest!

Re:it just seems appropriate

[Anonymous Coward]

You are standing in an open field, west of a white house with a boarded front door. There is a small mailbox here.

Re:it just seems appropriate

[jhantin]

Come on people, give it a REST.

Re:it just seems appropriate

[Art3x]

DELETE!

Re:it just seems appropriate

[aztracker1]

PUT!

Re:it just seems appropriate

[spongman]

oh, just imagine the OPTIONS!

Re:it just seems appropriate

[vegiVamp]

*snore*

Re:it just seems appropriate

[Anonymous Coward]

HEAD!

Re:it just seems appropriate

[HuckleCom]

PUT

Partially agree. Feature-control?

[Anonymous Coward]

Instead of using stupid, monolithic versioning methods, why not just do feature-based parsing?

Instead of doctypes for HTML5, for example, you have something that states what FEATURES you are using, and it only parses based on that.
So, if you want to use canvas, audio and video, you state something like <DOCTYPE canvas,audio,video>
Not only is this more specific, it saves on having to load parsers for stuff you don't have on the page at all.
Current objects can be exploded from generic-doctype-version to discrete groups, such as visual markup (bold, italics, strike), formatting (pres, tables), media (img, embed, object) and so on.

Seriously, why hasn't this been done yet? It is a much more efficient system and only just barely adds a slight increase in difficulty in generating documents since you need to activate the features through the doctype identifier. (if you don't, it doesn't get parsed, period)
Obviously it won't make a difference to the amateur web developers, they barely care about doctypes as it is, who cares about them? They will just google why their sites aren't working and find 100+ blogs on "how to get my websites working".

Yes, it is going to require a lot of work, but it doesn't mean it will break any websites, only old browsers. (and, yet again, who cares, that's what they get)
Thoughts?

Great Idea!

[dantaylor08]

All we'll have to do is build a separate page for every browser that visits our sites! Wonderful idea! /sarcasm

I can't up-moderate, so i'll just say it

[BlakJak-ZL1VMF]

+1 to everyone who thinks this is stupid. In particular given how significant HTML is to the web-as-we-know-it surely there must've been some consultation before making a call like this? With a cacaphony of "NO" coming through here (and very little, if any, support) one has to wonder....

Re:I can't up-moderate, so i'll just say it

[maxume]

html4 is still a standard. Major browsers are likely to support it for at least 20 more years, if not forever (especially in the sense that there is very little in the html5 working draft that breaks html4).

Re:I can't up-moderate, so i'll just say it

[Dracos]

If this is Hickson's idea, it certainly tops all the other terrible or poorly reasoned ideas he's come up with.

Re:I can't up-moderate, so i'll just say it

[u17]

I have a feeling that all this is arguing over the colour of the bike shed. It's just not important whether HTML is versioned or not, what's important is that the principles behind developing XHTML2 have been dumped, and instead of a strict, orderly and accessible standard, we've been left with a chaotic, disorganised jumble of hacks developed by people who don't seem to care at all about good design.

Bad engineering

[cjcela]

We are in the hands of morons. A constantly evolving standard is bad news for everybody except maybe a few companies that sell HTML development tools. Fast forward 10 years, and we will not be able to read half of the web, and will need 10 different browsers to see our usual choice of sites. There is a reason for versioning. Keeping up with a website will be a pain. I guess I should not complain, many people will have a job thanks to this.

Re:Bad engineering

[Anonymous Coward]

As long as HTML is still text, and I don't go crazy (probably because of broken support for everything in IEx), my development tools will be sound.

Re:Bad engineering

[DragonWriter]

A constantly evolving standard is bad news for everybody

The standard was, in fact, constantly evolving anyway, and all the browser vendors (and other heavily interested parties) were engaged in the process and doing pretty much exactly what they would do under a version-number-less process.

The only difference is that people that weren't deeply involved were dealing with snapshots that the major players were treating as outdated.

Re:Bad engineering

[Timmmm]

Just because it's constantly evolving doesn't mean they're going to make backwards-incompatible changes!

Re:Bad engineering

[Haeleth]

True, but the fact that they explicitly say they are going to make backwards-incompatible changes does.

Re:Bad engineering

[Anonymous Coward]

well, we've *had* version numbers all these years, and AFAICT it hasn't resulted in consistent support across all browsers, so from a pragmatic POV, even saying 'HTML4' isn't really something that's viable as an engineering decision - you're constantly having to accommodate what the (major) browsers do and don't support.

You'll notice the 'browser capabilities' sets of data in lots of existing web code now (web frameworks, javascript frameworks, etc) so this is more, IMHO, just acknowledging the reality that exists today.

Re:Bad engineering

[BZ]

> There is a reason for versioning.

Maybe, but it hasn't been used for HTML on the web before... there was just some pretending to version HTML going on. Not a single browser really versioned it.

Re:Bad engineering

[Anonymous Coward]

Yep, throughout the whole HTML5 debacle, working at Google or not, this Ian Hickson guy has shown nothing but to be completely inept in his understanding of good practice web development.

He throws XML markup aside as if it's unimportant whilst failing to realise many businesses wordwide need to do backwards compat. with black box software that outputs XHTML using XSL transforms, and that should such vendors start using HTML5 in future they'll be much more screwed.

He shows a complete lack of interest with regards to accessibility, he shows a complete lack of interest to support writing consistently formatted code by enabling a thousand different ways of doing things.

He mixes concerns, he has no grasp of the concept of separation of concerns, he thinks you can just lump everything in together and it'll be okay.

Whatever his experience is he clearly has zero experience of working on large scale web applications, he just has absolutely no grasp of even many fundamental principles of good practice software engineering.

This guy absolutely must have the future of the web ripped out of his hands ASAP, he's a more dangerous manipulator of web standards than even Microsoft ever was.

Mega LOL

[simpleguy]

HTML Gold
HTML Premium
HTML Elite
HTML Deluxe
HTML Pro

Re:Mega LOL

[rudy_wayne]

HTML Gold
HTML Premium
HTML Elite
HTML Deluxe
HTML Pro

You forgot HTML Pro Gold

Comment removed

[account_deleted]

Comment removed based on user account deletion

Er, Why use Version Numbers At All?

[swsuehr]

I broke the cardinal rule and read TFA. From TFA:

"Hickson mentions that the group will be dropping the HTML5 name immediately, but it we have not received a confirmation that this will happen over at the W3C as well."

So WHATWG will no longer be using numbers? WHATWG can call it "Hullapuhjelpus" as far as I'm concerned as long as W3C still continues using version numbers. Version numbers provide excellent reference points to featuresets and are useful to implementers, developers, and end users alike.
From the WHATWG Blog:

"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."

Because there's demand for new features you no longer want to use a numbering scheme? Many standards are evolving. Why not just increment the minor version when new features are added? HTML version 5.1 added this cool thing, 5.2 this cool thing, etc.

If we're dumping version numbers then why bother calling it Internet Explorer 6, 7, 8, and 9? Why not just call it "Internet Explorer"? We all know that each of those versions render pages the same, right? Hmm. I just realized that I invoked Internet Explorer in a discussion about standards. Mea Culpa.

How does removing the version number help the people who need to implement and work with the standard?

Re:Er, Why use Version Numbers At All?

[Bogtha]

How does removing the version number help the people who need to implement and work with the standard?

It doesn't, it's a fucking disaster. I'll give a concrete example. I used HTML 5 audio on a site with a Flash fallback for browsers that didn't support it. All is good and well. One day, I start getting complaints that the audio is broken. Turns out that a) the HTML 5 spec had changed and b) Firefox had changed to match in a minor point release. Firefox 3.51 worked, Firefox 3.5.2 didn't, as I recall. The new API was indistinguishable from the old API in as much as all the same objects and functions were there, but a return value had changed. So, even with the best practice method of feature detection, anybody writing to the old API was screwed.

So I fixed it up by removing the HTML 5 audio and made the decision to wait until HTML 5 was published in its final form. Something that I should have done to begin with really, it's madness to use HTML 5 at the moment as it's just not finished yet. You don't know what is going to change.

And now they want to do away with a "final" version altogether? Gee thanks, guys! How am I going to be able to trust it to be stable enough to rely on ever again? What's going to stop the same thing from happening over and over again?

Re:Er, Why use Version Numbers At All?

[St.Creed]

How does removing the version number help the people who need to implement and work with the standard?

It's not mean to help the implementers. It's meant to help out the marketeers...

Re:Er, Why use Version Numbers At All?

[Anonymous Coward]

You've touched upon something that many people in the web development community are just starting to wake up to, that Html5 is several years away, and always will be.

Re:Er, Why use Version Numbers At All?

[Anonymous Coward]

Exactly, they need more version numbers not fewer.

Please rollback

[MrJones]

bad choice, please rollback to html5. Then you can call it html5.1, html5.1.1, etc

It just does not make any sense to me to scrub the version number of an open specification.

Is this the new Google? Don't like it

Version numbers not related to issue

[DragonWriter]

You'll get pages that becomes invalid with time despite they were valid before.

That is a result of backward-incompatible changes, not the absence of version numbers.

Re:Version numbers not related to issue

[Anonymous Coward]

You'll get pages that becomes invalid with time despite they were valid before.

That is a result of backward-incompatible changes, not the absence of version numbers.

Version numbers are there to indicate whether the current version is backward-compatible with the version you used or not. It's impossible to avoid backward-incompatible changes altogether, and all the more so in an ever-changing "spec" without fixed, well-defined releases. The version you used may just be buggy, and removing a bug makes all future versions incompatible.

Re:Version numbers not related to issue

[EdIII]

You'll get pages that becomes invalid with time despite they were valid before.

That is a result of backward-incompatible changes, not the absence of version numbers.

Quite true, but what I think the poster was saying is that without version numbers it would be impossible to claim they were "standards" compliant at any one time. So even if you wrote very good code that was compatible across 99% of all browsers out there, a few years go by and you look like lazy morons that just don't care.

As for the backwards-incompatible changes, without version numbers you would really have no way to tell what you are doing anyways. Since you can't reference it by version number you would be forced to reference by a specific instance of a problem. The newest Firefox blah blah blah tends to have a problem with this, this, and this, and Opera v.x tends to have a problem with that, that, and that.

Next thing you know the browsers will go versionless too and then at that point all you can do is drink heavily.

Re:Version numbers not related to issue

[DragonWriter]

So even if you wrote very good code that was compatible across 99% of all browsers out there, a few years go by and you look like lazy morons that just don't care.

That doesn't happen unless the standard is accepting backwards-incompatible changes to widely-established features, which they've committed not to.

As for the backwards-incompatible changes, without version numbers you would really have no way to tell what you are doing anyways. Since you can't reference it by version number you would be forced to reference by a specific instance of a problem. The newest Firefox blah blah blah tends to have a problem with this, this, and this, and Opera v.x tends to have a problem with that, that, and that.

Which is what you have to do with features in the real world anyway.

Re:Version numbers not related to issue

[Bogtha]

You'll get pages that becomes invalid with time despite they were valid before.

That is a result of backward-incompatible changes, not the absence of version numbers.

No, that's not right at all. If a document is valid HTML 4.01 Strict (for example), then no amount of backward-incompatible changes to later versions of HTML will make that document invalid. Take away the version numbers and that is no longer the case.

Re:Version numbers not related to issue

[Haeleth]

That doesn't happen unless the standard is accepting backwards-incompatible changes to widely-established features, which they've committed not to.

Provided you only use "widely-established" features. Which ones are those, specifically? Because they certainly have not made any commitment to reject backwards-incompatible features in general. Quite the opposite: they make it very clear that if they decide something is "broken", they will change it without warning. Hope you weren't relying on that "broken" behaviour.

Re:Version numbers not related to issue

[DragonWriter]

Provided you only use "widely-established" features. Which ones are those, specifically? Because they certainly have not made any commitment to reject backwards-incompatible features in general. Quite the opposite: they make it very clear that if they decide something is "broken", they will change it without warning. Hope you weren't relying on that "broken" behaviour.

Here's the thing: they've already been doing that with the HTML5 spec. The only thing that has changed with respect to the current work with the "Living Standard" approach is that they are taking out the process which results in updated "snapshots" exposed to the public while the major browser vendors, etc., are using drafts that are more recent than the snapshots.

At least, that's the change they've identified.

Hope you weren't relying on that "broken" behaviour.

Since the WHATWG definition of "broken" seems to be "incorrect documentation of what browser vendors intended to commit to support", code that relies on something they would consider "broken" almost certainly wouldn't work in most browsers, and often wouldn't work in any browsers, anyhow.

Re:Version numbers not related to issue

[Anonymous Coward]

That is a result of backward-incompatible changes, not the absence of version numbers.

Wrong. Right now, if you have a valid HTML 3.2 page, it'll stay valid HTML 3.2 forever; it might not be valid HTML 4.01 or valid HTML 5, but that's a different matter.

If version numbers were dropped, you'd have a valid HTML page, and in ten years, chances are it wouldn't be valid anymore. Browsers would likely still attempt to render it (this isn't XML, after all), but I fail to see how it would be a good thing; the thought appears to be that noone's using older HTML standards, anyway, and that thus, browsers shouldn't have to keep the baggage necessary to render HTML 2.0 or 3.2 pages etc. around anymore, but... well, they still would. There just wouldn't be an easy way for them to tell which parsing/rendering mode would be appropriate anymore, so the end result would be more cruft, not less.

Re:Version numbers not related to issue

[Anonymous Coward]

You'll get pages that becomes invalid with time despite they were valid before.

That is a result of backward-incompatible changes, not the absence of version numbers.

But without version numbers, you won't easily know how far back to go.

Re:Version numbers not related to issue

[Anonymous Coward]

With version numbers browsers can sensibly handle backward compatible changes.

Re:Version numbers not related to issue

[Anonymous Coward]

While true, your statement misses the point.

With version numbers you can specify that this document is written in "!DOCTYPE HTML/4.0 STRICT" and the browser knows what that means.

Without versioning, if a certain syntax is deprecated in newspeak-HTML, how is a browser supposed to know whether it's parsing an older style of syntax or a plain old error?

Re:Version numbers not related to issue

[Anonymous Coward]

You'll get pages that becomes invalid with time despite they were valid before.

That is a result of backward-incompatible changes, not the absence of version numbers.

Yes, but the absence of version numbers means that when we need to make backward-incompatible changes in the future, we're going to have issues. It will happen sooner or later, even in the best designed standard.

Re:Version numbers not related to issue

[Mystra_x64]

Too good to be true. Browser will guess whether it needs "strict" rendering and that's about it. No one is going to have multiple ways to do things for all HTML or whatever versions. Other than legacy IE quirks mode.

Re:Version numbers not related to issue

[wunderbus]

So let's compare this situation with the one that existed right before the WHATWG made this announcement. You write a website that is compatible across 99% of browsers. You were writing for HTML5 so you put !DOCTYPE html at the top. After the WHATWG's decision to remove versioning from HTML, you put... !DOCTYPE html at the top.

You write a website and then abandon it for several years. You were writing for HTML5 so you used what actually worked with browsers at the time. After HTML5 became HTML, you... used what actually worked with browsers at the time.

I'm having a hard time coming up with any differences. Can you describe them to me? Are you actually a web developer?

"Without version numbers you would really have no way to tell what you are doing anyways." Oh, crap! Suddenly I've lost all my knowledge of browsers and web development. I should quit my job and go eat worms.

"Next thing you know the browsers will go versionless too and then at that point all you can do is drink heavily." Well, I already drink heavily, but I don't depend on user agent sniffing to make my websites. I'd rather use feature detection. Surely you know what that is, since you're an expert on web standards.

Your "insightful" mod is insulting. Yes, if you write a website and don't attend to it for years, you look like a lazy moron. But that's probably not because browser advances broke your website. Why don't you try out some deprecated tags and see if they work. They do! They all do. If you abandon your website for years, you'll look like a lazy moron because you abandoned your website for years.

Re:Version numbers not related to issue

[Anonymous Coward]

You'll get pages that becomes invalid with time despite they were valid before.

That is a result of backward-incompatible changes, not the absence of version numbers.

Looking at the source of this very /. page, I can see something called a doctype declaration.

While it is good practice to minimize backward-incompatible changes (so that older browsers still work reasonably), it is also good practice to declare the language (version) you are using so that browsers can behave accordingly. I love doctype declarations.

FWIW, I have not the slightest idea what the phrase "minimizing backward-incompatible changes in a version-less spec" actually means, so I'd suggest we'd rather skip that idea altogether.

Strange

[marcello_dl]

Funny distribution of approval on the linked blog's comments there (I hope not to have violated the rule of not RTFA I just read the comments there I swear).
First 10 comments, 2 negative. Last 10 (around n.50 as I write) 9 negative.

Shocking...

[mcsqueak]

Color me "not surprise". Engineers, much like artists, have a hard time knowing when something is done and want to "tweak and tweak" everything to death.

Solution? Rather than *finish* something, just remove the versions! It'll be in development for perpetuity - an engineer's dream come true.

HTML5 isn't supposed to be finalized until 2021

[Anonymous Coward]

Yes, 2021, this is a complete non-issue. The standard isn't terribly useful in the near term and no one will give a crap by then (as well, Google doesn't get to decide this).

Privacy dies in this move

[Khopesh]

I think the "vector of flags" idea has merit, but it introduces worse issues than those it solves. Consider privacy and user-tracking issues; this vector would make it trivial to uniquely identify users because it contains that much more information (see also the EFF's Panopticlick).

We still need "milestones" which can be marked, even if they are years, quarters, or months instead of versions. In this manner, we can still determine compatibility without introducing millions of different combinations of flags.

Another approach is the way javascript already does this. If there is a chance a function or object isn't supported, test it first, e.g. if ( document.getElementById ) { } It shouldn't be too hard to do this for HTML properties in a similar manner, perhaps like if ( document.supportsElement("video") ) { } (like document.createElement() but returning a boolean instead of an element). The important piece here is that there is no array containing this information. You would have to construct it if you really wanted it, which makes it harder to observe minor differences in ways that browsers structure it.

Re:Privacy dies in this move

[nschubach]

The only way I can think of doing that would be to use the id field as a named index (which it already is) and taking the first supported tag...

<video id="somevideo" />
<object id="somevideo" /> ...ignoring identical key objects placed later in the page. (I can see bad things taking the second item unless you encapsulate the id in the parent tag "scope")

Re:Privacy dies in this move

[Khopesh]

You're trying to support this given existing standards, I'm proposing an alteration to the standard.

It keys on an element in question, be it a tag name, attribute type, or something else entirely (each case would have its own implementation and/or would be an acceptable query string to the support detection function, which merely returns false if it doesn't recognize the input). Perhaps I should have named the function navigator.HTMLsupports() or navigator.supportedTagName() instead.

Next up!

[Haedrian]

HTML ME, closly followed by HTML XP

Fun with Names

[bill_mcgonigle]

if we can't even talk about it because it lacks a name.

Hey, we've seen this before - no numbers, but we can have HTML Pro, HTML Extreme, HTML on Acid, HTML JC, etc.

Seriously though, if there is a written standard, no matter what they don't call it, people will label it. HTML 2012, or whatever, will be what was in effect as of January 1st 2012.

Maybe what they're trying to do here isn't to keep browser writers from having excuses for not keeping up, but for keeping the standards body from feeling like if they put out an update every 15 years they're earning their keep.

Bad interpretation

[robmv]

What was said is that the moving spec in development is now called HTML, when a snapshot is taken it will be called HTML5, next HTMLX.X.X or any other name. The WHATWG spec is not a finalized document, HTML5 will be snapshoted sometime

Re:Bad interpretation

[freedumb2000]

mod op up

Re:Bad interpretation

[Anonymous Coward]

Which is up to the W3C to decide. Too much hyperbole over nothing...

Re:Bad interpretation

[mdmkolbe]

Did we read the same article? Because I don't see where it says that.

Re:Bad interpretation

[robmv]

quoting the original announcement

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

Welcome to HTML. The first rule of HTML is:

[Anonymous Coward]

Welcome to HTML. The first rule of HTML is: you do not talk about HTML. The second rule of HTML is: you DO NOT talk about HTML! Third rule of HTML: if someone yells "standards!", goes limp, or taps out, the fight is over.

If no numbers, at least snapshots

[jinushaun]

Ok, I understand the whole "living document" reason, but as developers, we're gonna need at the very least a snapshot of HTML from time to time. We need milestones/pseudo-versions. Otherwise, we're going back to the wild west days of IE4 and Netscape where the internet was a broken mess of incompatible websites each targeting a specific browser, instead of a common version of HTML.

Thanks for nothing, W3C. I guess HTML "5" become too much of a hot topic.

Chrome version numbers

[Anonymous Coward]

But Chrome does have version numbers. The releases have 3 _sub_version numbers (n.x.y.z)

HTML exercise 101

[Kupfernigk]

Hello world

<---this table won't display in any browser not updated to marshmallow level-->

No, it won't be as hard as that, it'll all happen in the css.

Disclaimer: I don't know anything about html, but you noticed that already.

Re:HTML exercise 101

[Nadaka]

You know enough to escape your braces.

Re:HTML exercise 101

[mcgrew]

Disclaimer: I don't know anything about html, but you noticed that already.

You know enough to write &lt for <. That's better than most slashdotters.

Prince?

[Anonymous Coward]

The artist formerly known as ... I mean, the standard formerly known as HTML5

A bit like Chrome?

[ninjacheeseburger]

But I'm running chrome 8.0.552.237 so clearly chrome is numbered, they don't need to call it anything else though as its automatically updated.

Forever in beta.

[westlake]

Ian Hickson, a Google engineer and editor of the HTML5 standard announced that the language will be transitioned to a 'living standard' without version numbers. A bit like like Chrome, if you will."

The HTML standards committee takes eternity and a day to finalize anything.

Which is how and why workable solutions - like Flash - that evolve outside the committee gain traction.

20% of peak hour Internet traffic in the states was a content-protected Netflix stream before Netflix offered a streaming-only service. HVEC - aka H.265 - will be ready in about two years. High Efficiency Video Coding / HEVC / H.265 : Beyond H.264

Half the bit rate of H.264 for content of the same quality...

Re:Forever in beta.

[Timmmm]

"Half the bit rate of H.264 for content of the same quality..."

If you believe that...

Re:Forever in beta.

[Art3x]

The HTML standards committee takes eternity and a day to finalize anything.

Exactly. Ten years passed between HTML 3 and 4. Another ten have now passed from 4 to 5, and 5 is still not an official standard.

Meantime, requests for features and API tweaks flow in, and all browsers are going ahead and building them (even IE!). If you froze the spec after so many features, you would be drafting HTML 8 before HTML 5 became standard.

Second, I don't know about you, but I write web apps for a living, and I've used HTML since 1997, and never once did version numbers help me. By the time I got serious, it was HTML 4. But none of the browsers posted anything like "we are an HTML 4 browser," and if they did, they lied, especially Internet Explorer. To know what worked, you tested and read about tests other people did on each the browsers.

Finally, the term "HTML 5" has already been stretched so much to be meaningless. I'm not even talking about the journalists who use it to mean things that you could do with 4. HTML 5 is huge: Canvas, video, audio, three persistent storage APIs and one session storage API, various APIs to do with the web address, geolocation, and others. Does a browser need to call itself HTML 4 until fully implements all of these? How would that help me?

The only thing I have ever really looked for are those comparison tables with the red and green squares, like we've always done, to figure out what to use in my web page next.

Re:Forever in beta.

[Phroggy]

WHATWG exists precisely because W3C was dragging their feet (and dragging them in a direction that neither browser makers nor web developers wanted to go). It was only after Hickson and WHATWG created HTML 5 that W3C woke up and said "oh, um, ok, I guess that will be our new standard!"

It's W3C that moves slowly, not WHATWG.

Re:Forever in beta.

[Bogtha]

Ten years passed between HTML 3 and 4.

That's not even close to being true. HTML 3 was published in draft form in 1994, but was scrapped when the browser vendors went off to do their own thing. Eventually, the interoperable parts of the crap that the browser vendors invented was codified as HTML 3.2 in January 1997. HTML 4 came along shortly afterwards in December 1997. At most you can say that there was a three year gap, but since nobody really counts the HTML 3 draft, in reality the gap between specifications is less than a year, not the decade you make it out to be.

I've also been a web developer since the 90s. In my experience, I've always been waiting for the browsers to catch up with the specs. I don't know how people can say that the W3C are too slow with a straight face. There's no point publishing spec after spec if the browsers are years behind them.

Standards? Bah! How does it render Acid3?

[hierofalcon]

I think most people stopped caring about the HTML standards a long time ago anyway. That is fine with me.

Today, everybody is focused on how the latest incarnation of a particular browser does on the latest incarnation of the acid test page. Does it render it correctly or not? If it renders OK, how fast does it do it? That's the bottom line anyway since most standards are not defined tightly enough to prevent various browser manufacturers from interpreting them ever so slightly differently while still claiming to be 100% (or less - cough) compliant.

It isn't a bad thing to say our site will work on any browser that can render the latest acid test page correctly. You can look at that page and limit yourself to a subset of those features during development of your site or your CMS system. A well developed test suite should work as well as some randomly numbered standard. Your browser either renders the page correctly or you go back and work on it some more till it does. Even if you're a big company, pages like the acid test page will eventually force you to make changes towards meeting a particular implementation of a standard, regardless of how much you like to resist change or how you'd like to interpret the standard.

Re:Standards? Bah! How does it render Acid3?

[Bloodwine77]

That is like saying you write a NET 1.1 app and the standard changes to where only .NET CLR 3.5 is utilized. You cannot guarantee that because your app worked perfectly during the .NET 1.1 era that it will obviously be flawless in the .NET 3.5 era. Let's apply the same logic to Acid3. Let's remove the version and just say, "does it render Acid??", where Acid is a constantly moving target. There has to be some way for developers to manually specify its target platform or renderer, and only moving to the latest standard AFTER they have thoroughly tested it. Especially in the world of web sites and web apps, downtime is pretty much a major no no. You can't go to your boss and say, "Well, it worked 3 weeks ago, I guess they must have changed the living standard on us. Sorry."

Re:Standards? Bah! How does it render Acid3?

[Waccoon]

Acid3 is passé. Now it's just "Acid." One test to rule them all.

Re:Standards? Bah! How does it render Acid3?

[BZ]

> most standards are not defined tightly enough to prevent various browser manufacturers
> from interpreting them ever so slightly differently

For what it's worth, the spec formerly known as HTML5 goes to great pains to NOT allow that. For example, the spec for the HTML5 parser is a state machine description that describes exactly how any stream of input bytes is parsed into a DOM (none of this "in an error case, do whatever you want" crap you see sometimes).

Re:Partially agree. Feature-control?

[Nadaka]

I'm sorry. The feature you are looking for is similar to XML namespaces (though such namespaces were much more verbose). A feature found in the XHTML2 standard that was rejected by the standards body because html5 went all the way to 5.

They'll use model-years

[Nimey]

Say hello to HTML 2011.

Re:They'll use model-years

[Exclamation mark!]

It's already 2011. Say hello to HTML 2012. Remember next year app marketing 101!

Re:They'll use model-years

[Nimey]

I was sort of hoping to avoid the retarded "OMG world ends in 2012!" comments, which is why I didn't go there.

HTML ME

[freedumb2000]

Awesome no numbers. Can't wait for HTML Vista or HTML Hardy Heron!

Dear Google

[Rockoon]

Please do not put the HTML5 spec onto a Google Wave page, thanks.

Wave failed. Just bury it, please. Don't take HTML5 with it.

Unique Keys

[Anonymous Coward]

Reminds me when the OOP newbies turned to the relational RDBMS people and declared, "We ain't need no unique key. We'll use object identity to keep track of stuff. It's the modern way".

A few months later a manager asks for an inventory report of all the stuff being tracked. The manager looked at the draft report and said, "Object people, how do I know that these two things with similar titles are not actually the same thing or that I select the right one to edit on screen after reviewing the report?"

"You can look at all the attributes and compare them", said one brave OOPer.

"ALL?!" asked the manager.

"Yeah, that better matches the real world. Rocks don't have ID numbers, for example", said the OOper.

"And like you guys now, rocks don't have jobs either", stated the manager.
   

Re:Partially agree. Feature-control?

[msclrhd]

Especially when you have the current mix of HTML4 or XHTML, RDFa, SVG and MathML. So how do you advertise that the site you are using supports HTML+RDFa+SVG (or some other combination)?

Living standard leads to broken web

[Bloodwine77]

I can't speak for all developers, but I need concrete targets to test feature sets. If you need to release more features more quickly, then start rolling out minor versions (HTML 5.2) or even go with the HTML X.Y.Z versioning scheme to add another layer of release intervals. Even if you remove all version information, the developer community will find a way to differentiate milestones of the living standard and come up with their own versioning scheme and ways of detecting "versions". That is, unless, there is no way to utilize older revisions and you must always use the most up-to-date revision. That will simply lead to a very broken web.

This comment written in HTML

[Anonymous Coward]

You are a fucking bastard.

Moving Targets

[theshowmecanuck]

Now browsers only have to support moving targets.

Re:Moving Targets

[Anonymous Coward]

Transitional and quirks mode forever!

A living 'standard'

[nurb432]

Is no standard at all, and will just be a mess. "ya, we are HTML compliant", which will become meaningless.

Can't be compliant with that...

[unil_1005]

..this is only good for the leaders: have a bright idea, throw in some junk, pull it out later when it turns out to be a mess. It's not "like" Chrome, it IS Chrome.

Re:Partially agree. Feature-control?

[Anonymous Coward]

Problem with XML namespaces are they are TOO specific. People really don't need that much control over pages, especially in the context of HTML development, outside of it being used to show a difference between versionX and Y.

Take Canvas as my previous example.
We have Canvas1.0, software only. Then we have Canvas2.0, hardware acceleration. (just examples, not reality)
The only reason i could think for having those 2 separate versions on the same page is to show the difference between them, that difference being mainly speed.

All of HTML development now is being designed with backwards compatibility in mind, as well as future proofing.
That is why Canvas, for example, has the ability to reference different context spaces (2D, webgl, probably others in the future)
It is highly unlikely there will be huge, B/C breaking changes done to anything now anyway, just new features added on top.

Developers will have finer control over their pages by just specifying the versions of the specifications of features there is in the global HTML space. (SVG, MathML or whatever)
We all know that nobody gives a damn about monolithic version support anyway, i don't think anyone even fully supports current specs fully, or correctly. (mainly because some of them are so horribly written in the first place, needs less optionals and more "MUST (OR GET OUT OF WEB BROWSER DEVELOPMENT)")
If nobody is going to support these huge feature sets, why not just split it up in to features and allow them to be targeted from the documents?
It is like buying a phone line, and getting TV and internet with it forced on top, with the price included, even if you never wanted it.
No point paying for content that isn't being used.
HTML5 is going to end up getting so big that the parsers are going to have figurative heart attacks. They are getting way too complex...

high-level abstraction is not suited to standards

[PJ6]

HTML to too high a level of abstraction to be maintained by a standards body; they are correct to move away from it so others - many others - can sort it out organically. We already have good lower-level candidates to take the place of a true web standard - Java and .NET (not Silverlight). HTML interpreters would then be libraries that the framework makers would provide, and web app developers would finally be freed from having to hack around the ass-backward idiocies of using markup and script to create user interfaces.

WTF!

[eko3]

What the fuck kind of crack is this guy smoking?

If the standard is "living", that makes it a moving target... and that means there will be practices that go away. When practice go away we call it deprecation. How the hell will a browser ever intrinsically know what is a "best practice" and what is "deprecated". For the love of God, we have hoardes and hoardes of peoples in "committees" that can't even make those decisions.

HTML version is what's been saving the whole intrawebs from blowing apart at the seems. !DOCTYPE is your browser's savior.

Good fucking luck with this one, buddy!

In other news...

[greg65535]

...Microsoft working on HTML6.

Re:In other news...

[lulalala]

And an individual is also working on HTML6:
http://xahlee.org/comp/html6.html
It's a mix of JSON and SXML:
The author also explains why unicode characters are used instead of the xml angle brackets.
It's quite funny, a must read.

this sounds familiar

[smisle]

Back in the day, didn't they proclaim that HTML 4 would be the final version, or was I just imagining that?

And - as a web developer ... *sigh* what are those guys thinking? It's bad enough that Internet Explorer can't just buckle down and pick a browser to work on, they are trying to do frequent releases like Chrome or Firefox, but without the cross compatibility that the others enjoy.

Standards

[Anonymous Coward]

The good thing about HTML standards is there are infinitely many to choose from.

STUPID!

[Anonymous Coward]

Thats the absolute stupidest thing I've ever heard! So now we won't know what versions browsers support and what to program to. This guy must have been paid off by MickeySoft.

GoodLuckWithThat

[scurvyj]

GoodLuckWithThat - any further questions?

It's not the spec that needs workarounds.

[gmor]

The DOM specs all provide spec-level testing (document.implementation.hasFeature(...)), but nobody uses that on the Web. Why? Because it's the browser bugs you typically have to work around, not backward-incompatible specifications. On top of browser bugs, you've got new user agents (iPhone) that the specs weren't designed for. And any experimental features will appear first in browsers before they turn into a specification, so developers will always use feature-testing instead of spec-level checks. Besides, feature-testing isn't as painful as you describe if you use libraries such as jQuery or Prototype.

Plugins?

[sourcerror]

Sounds like a plugin architecture. Which is not quite surprising considering they're planning to replace Flash and co.

A bit like google chrome?

[bdkraem]

*opens Chrome, clicks the little wrench, clicks "About Google Chrome", sees "GOOGLE CHROME (8.0.552.237)"* Yes, a living standard with no version number, a bit like Google Chrome, indeed.

April 1st already?

[upuv]

This can only be a joke.

Propritary extensions to the spec run amok. Sorry what spec that just leaves propritary extensions.

The only thing left common across the board is flash. Was the a major point of html5 to remove the need for plugins like flash?

I'm stupified by this annoucement.

Chrome has no version numbers???

[mestar]

"a 'living standard' without version numbers. A bit like Chrome, if you will."

Is that a bit like Chrome 8.0?

Chrome is propietary!

[Dratman]

It's ok for Chrome to be continuously updated without using publicly visible version numbers because it's a single-sourced proprietary service. There is no question about interoperability, because -- aside from the extensions interface -- Chrome only interacts with itself (one body of source code) and with the user. With respect to chrome, there is nothing to standardize.

not me shoot them

[Anonymous Coward]

For the love of god, if it's going to be like chrome we're all screwed. It's sad that soo many good projects try to make themselves so good they kill themselves. Take Firefox, Chrome, HTML 5, iPad (iPhone without a phone), free 411 (just pay your fee's and shut up).

No Fun

[Anonymous Coward]

Shucks.

I was hoping they would add some pizazzes and add colorfull hyphenated flavors to schnaze-up the joint.

Like:

HTML-Elephant

or

HTML-Speed.Erasure.

I am particullarly fond of,

HTML-H.M.S.Titanic.

Oh, here is one from Japan, back in my J-rock daze,

HTML-Three.Michelle.Gun.Elephant.

-308

The solution

[Anonymous Coward]

Here is the solution:

Add a classes tag, let users point to blobs of bytecode or plain source code somewhere.

Said code gets read in, executed and feed the remaining content of the page. Code renders page as see fit.

Naturally each tag would correspond to a class-name. Tags would be object definitions.

Of course, W3C would have to standardize the classes-tag so it is known what the blobs are (why not CLI / C# Ecma standard) and then on some api's for drawing primitives.

Doing it this way would utterly eliminate cross-browser problems, the content provider decides exactly how rendering is done by specifying classes in all browsers, down to the last pixel...

Let's imagine google wants to use WebM?

They then do this: ...
    http://www.google.com/classes/webm.class ...

                my-webm-movie.avi

That's it, code to read/render webm would be provided in source code or a byte code file. .....Infinitive possibilities and no browsers problems in the future.

No more version number

[Funnnny]

I will write a new blog platform that support html-r87384. Wordpress will become obsolete

Yes, WTF?

[Anonymous Coward]

Seriously, I've had major reservations about HTML5, and one of my key complaints was the arbitrary nature of the semantic tags. I pointed out that although the tags were decided based on research of common id's on existing web pages, the web is not static. Already I believe it's likely a rise in "comment" for example is likely with the rise of web 2.0 and so you have to resort to using some divs anyway, more and more as time goes on. You might as well keep your code consistent and just use divs and keep id's and classes, with which semantic information could be attached in a similar way to the way styles are with CSS- in fact, this route would even allow browser and 3rd party sites to provide semantic information for sites that are no longer updated.

It seems the solution now is to simply just not even bother having a standard, and just have "Hixie's box of shit" that changes as and when he sees fit, seriously who made him "Grand ruler of the interwebs"?

I know the W3C was far from perfect, but at least things were decided on based on input from many different groups in many different areas. When I questioned the lack of improvement, and in fact, the likely decrease in support for accessibility in HTML5 the only response I got was along the lines of "Accessibility isn't HTML5's concern".

Please, PLEASE let's go back to the XHTML route because although it was far from perfect, at least the people developing it weren't inept and egoistical. HTML5 just seems to get worse and worse, whilst some features are nice they'd be better implemented in a "proper" spec. Coupled with the trend towards sloppy mark up rather than XML which is easily parsed and transformed in just about every language and framework imaginable HTML5 looks set to be an unimitigated disaster for the future of the web. We really are bag to the days where we have lots of obscure messy features, that are implemented differently on different browsers. We've already seen evidence of this where both Google and Apple have produced HTML5 demos that don't work properly outside their own browsers.

With this latest news our development team absolutely will not be using HTML5. It is simply not a standard suitable for professional enterprise web applications. Hixie can take his raping of the web and go fuck himself with it. If HTML5 had stuck to one of it's key goals of standardising obscurities that different browsers had snuck onto the web over the years it wouldn't be so bad, but the way it's trying to change the entire landscape of the web by undoing all the work done to push people towards more consistent, more easily parsable, more standardised markup and the benefits that brings in terms of interop and greatly increased accessibility is utterly fucking dumb. Not only that now, but he's trying to even redefine what a standard is and how it works?

"Oh I like your new HTML5 compliant cell phone Jim, too bad it wont be compliant when the spec changes tommorrow and fucks things up for you"

stupid engineers..

[SuperDre]

And who decides what the new versions of HTML will support? It looks more to me that Google is trying to take over the whole internet.. Versioning is needed no matter how you see it.. And how will the new 'HTML' standard evolve? the whole thing only seems to me that it will be one big BIG mess if nothing is really agreed on by many people..

You forgot..

[Anonymous Coward]

HTML: Electric Boogaloo

Direct3D model

[fleeped]

Direct3D 9 had CAPS ( capabilities ) bits which queried the gfx card for feature support. That was THE total nightmare for programmers, for reasons previously described. Direct3D 10/11 was improved to having version numbers ( 9_1, 9_2, 9_3, 10_0, 10_1, 11) to indicate hw-supported features. So the programmers have now a total of 6 permutations. This is called RATIONAL SOLUTION and it's great. So the HTML guys are going backwards on this? Rrrright...

sounds like Hixie

[Anonymous Coward]

Hixie likes having control of the revision process, and working to his own dictates. Not having version number or a schedule suits him perfectly. This is, after all, the guy who issued 76 versions of his draft-hixie-thewebsocketprotocol internet draft and drove implementers nuts. He was then removed as document editor, much to the acclaim of the IETF hybi working group. Sadly, it appears that the dysfunctional W3C, where Google has more power, is somewhat slower on the uptake.

The standards are too complex

[bradley13]

HTML 2/3/4, XHTML/1, and CSS/1 were all small, simple, understandable standards. Then the web got popular - in part because web standards and technology were so simple. Once the web had exploded, every damn company wanted to stick its oar in. CSS 2 took years, is overly complicated, but still just barely manageable. Look at CSS 3 - everybody's special wishes are in there - the thing is immensely complex and as a standard, frankly, it is therefore nearly useless. HTML 5 is much the same - too many special wishes and fancy features. One needs to take a weed-whacker to it and to CSS, to restore some degree of simplicity.

Think of it this way: why is there a competition to see how well browsers score on the ACID tests? The standards ought to be simple enough that any decent browser scores 100%. The fact that this is not the case is proof that the standards are far, far too complex.

Re:The standards are too complex

[Anonymous Coward]

I wish I had modpoints

Sounds fine to me.

[dhammond]

Honestly. As a web developer who works in the real world with real client demands, I have never worried much about targeting a specific version of the html spec. I use best practices when I can, and hacks when I have to. The real goal is to get a site working for as many users as practical. The sole purpose of a doctype in a web page is to alert browsers such as Firefox and IE to use their "strict" modes rather than their "quirky" modes. There has never been a time when I have been able to rely on writing to a standard and having it work in every browser I need to support, and it's unreasonable to expect that to change any time soon.

Specs should use a time based model

[pigsflew]

They should commit to following a schedule so that requested features can become standards faster--and then left alone.

Something like:

Every 12 months, a draft is released with new features that were written up into the standard over the last 9 months. This constitutes a feature freeze.
At that time, the entire draft is read and each feature voted on. Some features may be tossed back for revisions or suggestions.

Within 3 months after the initial draft vote, these features may be resubmitted with changes and reconsidered for inclusion.
3 months after release, the draft, with all accepted features and none else, is finalized.

This way each final version will really have a bunch of "improvements" over the last version, and one or two major "new" features. But given 5 years, we'd have standardized more new features than they have in 10.

Perhaps they should do a longer timescale than a year, so that browsers will be able to develop the necessary things to support the latest standard while it's still a standard...

(note: i realize this is very similar to the timed release patterns of many large open source projects--I just think the concept of enforcing incremental, iterative improvement is a good one.)