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]

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.

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

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

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

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

[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!

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

[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

[Chris Mattern]

Actually, the reboot will be "HTML Begins"

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

[sgbett]

HTML 0

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

[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

[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

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

[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

[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

[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

[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?

[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

[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?

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

[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?

[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?

[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

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

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!

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.

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?

[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?

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

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.

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.

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.

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:Idiocracy

[denis-The-menace]

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

it just seems appropriate

[Anonymous Coward]

GET!

Re:it just seems appropriate

[gorzek]

REST!

Re:it just seems appropriate

[Canazza]

SOAP!

Re:it just seems appropriate

[ManuelH]

XMLHttpRequest!

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

[HuckleCom]

PUT

Re:Irrelevant information about irrelevant topic.

[h4rr4r]

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

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

[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

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

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

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

[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

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

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.

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

[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).

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!

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.

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:Irrelevant information about irrelevant topic.

[Panaflex]

Howard Moskowitz - Spaghetti Sauce!

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.

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:HTML exercise 101

[Nadaka]

You know enough to escape your braces.

Re:Mega LOL

[rudy_wayne]

HTML Gold
HTML Premium
HTML Elite
HTML Deluxe
HTML Pro

You forgot HTML Pro Gold

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.

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.

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

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.

Moving Targets

[theshowmecanuck]

Now browsers only have to support moving targets.

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.

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.

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.

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.

No more version number

[Funnnny]

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

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

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.

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.

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.

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