HTML is the new HTML5 (The WHATWG Blog) [LWN.net]

Ian Hickson introduces the end to version numbers for the HTML specification. "The WHATWG HTML spec can now be considered a "living standard". It's more mature than any version of the HTML specification to date, so it made no sense for us to keep referring to it as merely a draft. We will no longer be following the "snapshot" model of spec development, with the occasional "call for comments", "call for implementations", and so forth." (Thanks to Paul Wise)

to post comments

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 24, 2011 21:39 UTC (Mon) by brouhaha (guest, #1698) [Link] (4 responses)

Thanks, guys. Before it was merely difficult to determine whether a piece of software was compliant with the HTML standard. Now it will be impossible.

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 24, 2011 23:43 UTC (Mon) by DOT (subscriber, #58786) [Link] (1 responses)

It was and still is very easy: the answer is always no. No software is compliant with any HTML standard.

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 0:22 UTC (Tue) by bojan (subscriber, #14302) [Link]

Both of the above comments are absolutely priceless! Thanks guys - really had a good chuckle :-)

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 17:07 UTC (Tue) by lambda (subscriber, #40735) [Link] (1 responses)

No. Before it was impossible. Now it remains impossible. This doesn't actually change much, other than the illusion that there was a stable target to aim at, when in practice, there has never been such a thing (or at least, nothing that was particularly useful).

Web browser development does not, in fact, happen by someone writing a full spec, then giving it to the browsers to implement, then the browsers implement the entire thing perfectly, then they start work on a new spec. Instead, sometimes browsers implement proprietary features, that people find useful and start using. Sometimes other browsers pick up those features, or offer something equivalent but not quite the same; at some point, someone takes the initiative to try and define a standard that satisfies everyone involved. Sometimes you do have people sit down and write a spec first, but then when people implement it in browsers, you realize there are serious design issues and need to go back to the drawing board.

Producing versioned specs, and demanding strict adherence to them, is akin to the waterfall model of software development, except even worse as you need to wait for multiple independent vendors to implement something, and release it, and have everyone upgrade, before it becomes particularly useful.

And be aware, this change is only to the WHATWG process, no the W3C process. For people who want tidy, versioned specs, which come out slowly and trail browser development by years, they can get that from the W3C. This is basically just admitting that the WHATWG is less interested in these snapshots, and more interested in helping browser vendors actually standardize on new features, even if there happen to be other, unrelated features, which are unfinished.

The place of standards

Posted Jan 25, 2011 17:29 UTC (Tue) by jrn (subscriber, #64214) [Link]

Nor does development against most standards take place according to a spec. The standards get written based on development and development gets influenced by the standards.

The value of versioned standards tends to be that the semantics of an unchanging, historical artifact --- a document or an application --- are clearer. And (parts of) standards can be validated against to help make sure that is possible.

As long as there is some versioning (HTML 2011-01-25?), I think we'll be okay.

A standard should be a statue

Posted Jan 24, 2011 22:03 UTC (Mon) by atai (subscriber, #10977) [Link]

or a series of statues with different creation dates (version numbers)

Post!

Posted Jan 24, 2011 22:12 UTC (Mon) by dskoll (subscriber, #1630) [Link]

Now "Post" doesn't need a number, either.

Crap. I didn't get Post. I got Post instead. :(

But seriously....

Posted Jan 24, 2011 22:21 UTC (Mon) by dskoll (subscriber, #1630) [Link] (1 responses)

This belongs on thedailywtf.com. The whole point of a standard is to be a stable, (ideally) unambiguous reference point against which implementations can test their compliance. An ever-changing "living" document is a big FAIL.

But seriously....

Posted Jan 26, 2011 8:03 UTC (Wed) by AlexHudson (guest, #41828) [Link]

I seriously don't think that's the case at all: if anything, it's much more reflective of the real world in which the standard actually operates.

The issue isn't "is the standard living", it's "how does the standard live". If the HTML5 people take it forward in a such a manner that it remains 99% backward and forward compatible, it will work brilliantly. If they attempted to turn this live document piece-by-piece into XHTML2, it will fail miserably. The reason for that is that HTML is widely and broadly implemented, and you absolutely have to take into account new browsers parsing old HTML and old browsers parsing new: if either of those situations doesn't work, the "new HTML" (whatever it is) doesn't work.

In fact, a standard based on gradual evolution, not planned revolution, is exactly what is needed. I don't understand why anyone would want to try the "big committee agreeing fixed new text every few years" type affair: it failed for HTML, it failed for CSS, it doesn't seem to work terribly well for Javascript or other key technologies. A living standard could hardly make the situation worse.

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 24, 2011 22:38 UTC (Mon) by b7j0c (guest, #27559) [Link]

the whatwg is becoming a parody of itself

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 24, 2011 23:11 UTC (Mon) by SEJeff (guest, #51588) [Link] (3 responses)

Girls girls, you're all pretty. This is lwn, and not /.

Please treat accordingly.

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 0:49 UTC (Tue) by drag (guest, #31333) [Link]

It's difficult not to react negatively. It seems to be a product of insanity.

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 1:36 UTC (Tue) by JoeBuck (subscriber, #2330) [Link]

SEJeff: careful, Joanna might be reading this.

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 1:37 UTC (Tue) by daniel (guest, #3181) [Link]

Hi Jeff,

A stupid idea is a stupid idea whether it is discussed on Slashdot or LWN.

Regards,

Daniel

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 24, 2011 23:23 UTC (Mon) by robert_s (subscriber, #42402) [Link] (10 responses)

So... what are we supposed to validate against?

I have a feeling we're going to look back on 2010 as a golden age of browser compatibility. It's not very good, is it?

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 0:03 UTC (Tue) by jreiser (subscriber, #11027) [Link] (1 responses)

what are we supposed to validate against?

A proper citation is the URL and the date+time that you retrieved it. (Obviously public archives just became even more important.)

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 12:22 UTC (Tue) by sorpigal (subscriber, #36106) [Link]

Great, so if you get the spec it at 5AM on Tuesday and I get it at 6AM on Wednesday, should our implementations match? One nice thing about version numbers is that you can perform equality tests.

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 0:24 UTC (Tue) by josh (subscriber, #17465) [Link] (4 responses)

As always, you validate against the standard today, and you choose what subset of it to use based on what the browsers you care about actually implement. Then if you want to add newer features from a newer version of the standard, you validate against that version of the standard, and again choose the subset you can use.

I don't think this announcement means HTML will stop having any versioning at all. This just means that HTML will stop following the model of "add a pile of features, then nail down a fixed point that doesn't change for years". That model leads to sites having to use browser-specific extensions for the latest functionality, which browsers sometimes choose to cooperatively develop and sometimes not. On the other hand, following a "release early, release often" model for the standard allows quick rounds of browser prototyping, early adoption and testing, standardization, and widespread use, without having to spend years relying on ad-hoc semi-standard functionality in specific browsers. Consider how long people used XMLHTTPRequest before it became a standard.

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 1:00 UTC (Tue) by proski (guest, #104) [Link] (1 responses)

Unfortunately, the announcement doesn't mention any better versioning mechanism. I see no point in announcing that the existing versioning will be obsoleted without saying a single word about plans to replace it with something better if such plans exist. This is misleading and misses a chance to attract attention of the recipients to what really matters (the new versioning mechanism).

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 1:41 UTC (Tue) by daniel (guest, #3181) [Link]

They say something about a "living" standard. I read that as "creeping". Or maybe "zombie", I'm torn.

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 12:25 UTC (Tue) by sorpigal (subscriber, #36106) [Link] (1 responses)

If that's the goal they should simply move to a frequent release model, Linux-style. Every three months a new version: HTML5.2, HTML5.2.16, etc.. Eliminating version numbers seems silly.

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 17:55 UTC (Tue) by lambda (subscriber, #40735) [Link]

Why? What value does validating against a particular version provide, as opposed to simply validating against the latest? Remember, too, that the validator will never be exactly in sync with the spec. The validator checks a lot more than what can be checked with a DTD (no DTD or other formal schema is even defined any more, since the requirements of HTML don't map well to most formal schema languages; validator.nu used its own Relax-NG schema plus a bunch of custom code). So really, you're validating against a particular validator version, not against a particular standard, and the validator will generally try and be as close as possible to the current version of the spec.

Really, validation is akin to warnings in a compiler. Some of them are important (if you have mismatched tags, or leave quotes off of an attribute that needs to be quoted), while some of them are more stylistic warnings. You generally want to adhere to the latest set of warnings, but have the option of turning off some spurious warnings or stylistic warnings that you don't agree with. I don't really see why you'd want to be using the warnings from 10 years ago for content that will be running on the web today.

I think that giving validators more options for suppressing certain classes of warnings or errors would be more valuable than adding some kind of arbitrary version numbers that don't really help anyone achieve anything particularly useful.

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 9:32 UTC (Tue) by jezuch (subscriber, #52988) [Link]

I guess (or at least that's how I would try to do it) we would validate against *features*, not the entire thing. You know, like the <video> tag. We don't need the whole of HTML5 to have it.

The devil is in the details, of course.

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 17:18 UTC (Tue) by tjc (guest, #137) [Link] (1 responses)

> So... what are we supposed to validate against?

I've been wondering the same. I could be in bed sleeping when suddenly, unbeknownst to me, all my HTML becomes invalid.

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 19:35 UTC (Tue) by foom (subscriber, #14868) [Link]

Yeah, but, if you were writing to the official HTML4 document, your document would've been invalid already. No web browser has ever implemented HTML4, so validating against that has been pretty worthless for its entire existence.

I mean, this is supposedly valid HTML syntax, according to the last released version of the spec:
<html<head<title/Foo/</><body<p<a href="foo"/text/</></body>

the WHATWG FAQ on this issue

Posted Jan 25, 2011 2:42 UTC (Tue) by stevenj (guest, #421) [Link] (1 responses)

See:

What does "Living Standard" mean?

and related items in their FAQ where they respond to the firestorm of protest over this move. Whether their responses are satisfactory is another matter, but at least they shed some further light on WHATWG's intentions.

not convinced

Posted Jan 25, 2011 10:25 UTC (Tue) by coriordan (guest, #7544) [Link]

I'm not convinced.

None of the advantages they mention require getting rid of version numbers.

Their example is that HTML4.0's "media=screen" was an error, and it should have been "media=all", and that by having a "Living Standard", they can fix such errors.

Ok, but that doesn't mean that HTML can't continue to have version numbers.

They could still publish "HTML5" and fix minor errors in the future. And they could publish HTML6 (maybe in 2016) and they could also fix minor bugs in that.

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 2:42 UTC (Tue) by dannyobrien (subscriber, #25583) [Link]

It's worth reading Hixie's FAQ before commenting (for or against) the "Living Standard" approach. http://wiki.whatwg.org/wiki/FAQ#What_does_.22Living_Stand...

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 3:35 UTC (Tue) by cmccabe (guest, #60281) [Link] (11 responses)

As the wiki page says, "If browsers don't widely implement a feature," then "it will be removed." Conversely, if implementations aren't "updated to reflect the new design", then "that indicates the new design is not good, and it will be reworked or removed."

So browsers are always conforming, because the standard consists of what browsers conform to! Brilliant! Donuts all around.

Seriously, though, WHATWG just became an overgrown Bugzilla for Microsoft, Mozilla, Google, and Apple. The "standard" is now basically a comment box that you can drop notes into in hopes that the Mozilla, Chrome, IE, and Safari engineers will read them.

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 5:16 UTC (Tue) by raven667 (subscriber, #5198) [Link] (6 responses)

I'm not sure that what you say is a bad thing, standards work better when they describe actually existing behavior and are not purely aspirational. The standards bodies aren't out there to lead the vendors around by the nose, they are there so that the vendors agree on a standard and can interoperate. In this announcement they are merely acknowledging the facts of how web standards have been developed over the last 5 years.

The push in recent years of browser vendors rallying around the standards is a process that I look forward to continuing under e guidance of the WHATWG.

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 6:56 UTC (Tue) by cmccabe (guest, #60281) [Link] (5 responses)

Thinking about this a little deeper, my interpretation is now the following:

Google wants to move fast with HTML. But adding features into an "official" version of HTML requires consensus among all the interested parties. It's a bureaucratic process. Consensus is hard to get, especially when two of the main interested parties, Apple and Microsoft, have existing thick-client businesses they want to protect.

So Google wants to forget about standardization for a little while. But saying "forget about the standard" sounds bad. So they use the euphemism "living standard" instead. Next, Google will add a bunch of new individual features to HTML. Once users start to like their Chrome / ChromeOS experience better, Google will push for those features to be included in IE and Safari too.

Website authors will keep doing what website authors have always done-- check for browser identification strings and coding to the browser, not the standard.

Viewed in this context, it all starts to make sense. Then again, maybe I'nm reading too much into this.

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 8:15 UTC (Tue) by dlang (guest, #313) [Link]

that is exactly the type of thing that microsoft attempted to do (without the 'push other browsers to implement' step), you really don't want to give large companies that sort of power

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 20:07 UTC (Tue) by coriordan (guest, #7544) [Link] (1 responses)

> Website authors will keep doing what website authors have always done-- check for browser identification strings

That's fine for organisations with a few web programmers, or for sites running some framework, but what about people like me who just want to write a few simple pages for homepage. I've no scripting or browser detection stuff, and I don't test my homepage with all the top browsers. I just read the spec and expect browsers to parser my valid html.

Do I have to get off the bus at this stop?

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 21:22 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

That seems a rather unrealistic strategy that would have ever worked properly. No reason to roll your own in the age of simple and flexible solutions out there. In other words, you never got into the bus.

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 26, 2011 20:40 UTC (Wed) by Simetrical (guest, #53439) [Link] (1 responses)

(Conflict-of-interest disclaimer: I'm currently working on a contract with Google to write web standards, supervised by Ian Hickson.)

Hixie happens to work for Google, but his decisions are his own. This is not part of some big strategic plan by Google. I think you'll find that Mozilla, Opera, and Apple employees who participate in the WHATWG are supportive of the "living standard" development model too. There have been complaints more than once in at least the W3C's CSSWG about how there aren't prominent enough links from Working Drafts (= outdated snapshots) to current Editor's Drafts (= up-to-date version). The current W3C model is just broken given how web standards are actually implemented.

(Microsoft, of course, has never participated in the WHATWG in any official capacity, so anything relating to Microsoft seems irrelevant here.)

I also don't think it's accurate to imply that Hixie treats requests by Chrome developers any differently from requests by other browsers. I've never noticed that. E.g., at <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-...>, he replies to a Google-employed WebKit developer's feature request by calling it "very odd" and requiring more explanation before he'll consider making any change, just like he does for anyone.

Hixie has publicly said (somewhere, I can't remember where) that he's been explicitly instructed by Google to edit specifications in the long-term interest of the web, not for Google's benefit. I have seen no reason to doubt this in the few years I've known him and watched his standards work.

HTML is the new HTML5 (The WHATWG Blog)

Posted Feb 1, 2011 1:20 UTC (Tue) by cmccabe (guest, #60281) [Link]

Thanks for the clarification.

I hope my post didn't make Google's (or anyone else's) plans for HTML sound sinister. I really think the current process will lead to a more powerful HTML. But I do think the cost will a de-emphasis on standardization, at least for now.

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 5:35 UTC (Tue) by kevinm (guest, #69913) [Link]

I'm reminded of this Far Side cartoon.

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 6:39 UTC (Tue) by njs (subscriber, #40338) [Link] (2 responses)

> The "standard" is now basically a comment box that you can drop notes into in hopes that the Mozilla, Chrome, IE, and Safari engineers will read them.

It's the other way around -- and always has been, since the inception of WHATWG (i.e., since the standard actually started mattering again). If you can convince Mozilla, WebKit, etc. engineers to do something, then it gets added to the standard.

This may seem backward, but it means that instead of all making up their own, incompatible random extensions, they agree on shared, compatible random extensions. Which is really the best possible outcome.

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 13:13 UTC (Tue) by ggiunta (guest, #30983) [Link] (1 responses)

Might be the best for the browser makers that participate in the wg.
Gonna be a lot harder for
- new browser implementations
- html as a "document format"
This second point is very important imho. It's being dumped in favour of 'the web is all about apps anyway and structured documents come from databases'. It's even stated in plain terms by the authors...

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 16:33 UTC (Tue) by njs (subscriber, #40338) [Link]

How so? The current HTML spec is *way* more accurate (in terms of actually describing reality) and detailed (in terms of actually being useful to implementors) than anything we've had before.

And one of the WHATWG iron rules is to maintain backwards compatibility, so I can hardly see how anything is being "dumped".

Death To Version Numbers

Posted Jan 25, 2011 6:16 UTC (Tue) by ldo (guest, #40946) [Link] (1 responses)

Whatever your ideological position is on this, its irrelevant. WHATWG is simply recognizing the reality of the way the world works, like it or not.

And as somebody who has been involved with both specification and implementation of file formats, I have to point outwho cares about version numbers? What happens when a data reader encounters a version number it doesnt know about: give upin which case it is being treated as a different, incompatible format, or continuein which case the number is effectively being ignored and treated as a number that the reader knows about?

Always check directly for supported features, not for version numbers.

Death To Version Numbers

Posted Jan 25, 2011 16:15 UTC (Tue) by spaetz (guest, #32870) [Link]

> WHATWG is simply recognizing the reality of the way the world works, like it or not.
It recognizes that html doesn't need versioning numbers? Looking at the comments around here, this seems to be a disputed reality.

> I have to point outwho cares about version numbers?

Everyone whining, err, complaining here?

> Always check directly for supported features, not for version numbers.

Right, but the supported features vary, just as well as the options for features. So by changing defaults from media="screen" to "all" (which is a sane change in itself), you have no idea of what the other actually intended, you are at the whim of the browser implementations of the day.
html4.01 media defaults to "screen", those of html5 to "all", that would have been less ambiguous.

Jst propose to do away with Linux Kernel Versioning Numbers and wait for the reactions. Version numbers ARE important, if only for their symbolic value. Otherwise people wouldn't get so riled up on whether something is called Linux 2.6.x or 2.8.x :-)

Unprofessional and counterproductive

Posted Jan 25, 2011 10:55 UTC (Tue) by job (guest, #670) [Link]

This is completely crazy.

I will never be able to order a "HTML" compliant document from someone because there is nothing to validate it against. I'm sure my web guy can find some historical combination that allows his vendor-specific extensions of the day.

Validation will be impossible in practice. A lot of syntax came and went durint the history of HTML, such as self closing syntax, default character set, etc. There is simply no reason to assume this rate of change will suddenly cool down, but plenty evidence of the opposite.

All this will accomplish is that it will be close to impossible to fork the HTML standard like WHATWG did to get HTML5 started, since it will be hard to reference a HTML6 in a future where WHATWG has gone stale. Further development from there would be a very messy affair.

I find this very unprofessional. Simply put, a non-versioned living standard is a contradiction in terms.

HTML is the new HTML5 (The WHATWG Blog)

Posted Jan 25, 2011 16:40 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (1 responses)

Perhaps a better perspective would be this:

HTML has grown. It has passed the point where it makes sense to treat it as a single monolithic block. Time to specialise.

We are used to such specialisation when it is called out specifically in the system design. The HTTP compression features, for example, leave it open to a future document to define a new standard compression (say, based on IBM's patents which ought to expire this decade) without needing a new version of HTTP. We certainly don't expect constant revisions of the Internet Protocol RFCs for every new IP-based protocol someone comes up with, even the matter of allocating them a protocol number is handled without touching the original standard.

There are some downsides to specialising. It's possible that your design, while solving the problem you were focused on, makes no sense in contexts that are visible to people working on other aspects. For security this is critical, any new HTML feature needs security consideration (like the requirement in modern RFCs) but for most other issues it's a mere inconvenience. So what if your <vuvuzela> element doesn't consider accessibility and i18n? A new <sportsnoise> element can be defined to address that later.

But mostly specialising frees up experts to get the job done on a timetable that's appropriate to their problem, and with the appropriate level of backward compatibility, or none. In particular it frees them from irrelevant (to them) and perhaps endless debates on some issue that holds up a monolithic standard, for example <video> codecs shouldn't be blocking progress on improving user authentication.

Of course it's not clear that WHATWG plans to do this, but it makes more sense than trying to continue to develop an ever-growing monolithic HTML.

On the need to keep up

Posted Jan 29, 2011 15:12 UTC (Sat) by CChittleborough (subscriber, #60775) [Link]

Many of the previous commentators seem to think Hixie and the WHAT-WG have decided to change direction. Not so. Instead they have formalized a change which happened at least a year ago. (I noticed this from reading a few Mozilla blogs, even though I don't pay much attention to WHAT-WG itself.)

HTML[5] consists of a nearly-stable core (markup syntax & semantics, network usage, etc) plus a bunch of regions (for lack of a better word). Some of those regions are just as stable as the core; others are practically guaranteed to change. As you would expect, the newer stuff is generally less stable.

(In theory, it would be possible to modularize HTML and develop/standardize each area separately. In practice, the interconnections are too strong and the boundaries between areas too changeable for that to work. But we can and should use terms like "HTML5 Channel Messaging" or "HTML5 Web Workers" to refer to informal modules within the HTML 5 project.)

Web developers wanting to use new features should write JavaScript that checks its environment. Eg.,

    if ( window.PostMessage )
        start_messaging();
    else
        tell_user("Your browser does not support Cross Document Messaging",
                  "Some features of this website will not work");

JavaScript code that checks HTML version numbers was never a good idea. These days it is a very bad idea.

As some earlier commentators have said, this gives Mozilla, Opera, and Apple a great deal of control over HTML 5. At least two of these (I don't know about Apple) are trying hard to make HTML as good as possible for everyone, not just themselves. Good luck to them.