HTML5 is now "HTML"

WHATWG now specializing in marketing.

[JAB Creations]

WHATWG has decided that removing the version number from HTML5 [blog.whatwg.org] and simply calling it "HTML" has benefits.

*double face palm*

- John

• The HTML specification will henceforth just be known as "HTML", with the URL [whatwg.org...] (We will also continue to maintain the Web Applications 1.0 specification that contains HTML and a number of related APIs like Web Storage, Web Workers, and Server-Sent Events.)
  
  
• 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.

[pcunite]

What disgusts me is that like forever, XHTML being sent as text/html was "the way" to go. Now we are supposed to migrate back to HTML style closing tags? I know, I know... HTML5 supports both so it does not matter thankfully. It is all just a bunch of unnecessary confusion by some very selfish companies. Ther're making us out to be a bunch of idiots for trying XHTML in the first place.

[topr8]

>>What disgusts me is that like forever, XHTML being sent as text/html was "the way" to go

personally i never used xhtml and i don't know who was saying it was 'the way to go' - uninformed bloggers mostly i think.

[kaled]

It's interesting that everyone on that link seems to think this is good idea but it seems bonkers to me. Instead of version numbers, in practice, dates will have to be used - precisely how is that an advance?

The purpose of version numbers is more or less the same as standards themselves - to provide a target for developers to work to. Without version numbers, website developers will have to check browser feature lists and without version numbers, how will the inclusion of new features into HTML be publicised?

My vote is that this is idealistic claptrap.

Kaled.

[mattur]

The purpose of version numbers is more or less the same as standards themselves - to provide a target for developers to work to.

See the FAQ page:

How do we know what to use, without having some sort of snapshot that browsers can aim at and developers can evaluate? [wiki.whatwg.org]

[JAB Creations]

Lame excuses plus if no browser implemented all of HTML4 then all the browsers only have partial HTML4 support.

We know that with HTML5 and CSS3 that the standards are growing very large which is why CSS3 is referred to as modules. Which CSS3 modules does a browser support? Removing a version number automatically implies when you are asked what a browser supports you then have to go through the entire list which is absolutely absurd.

Removing the version number dumbs everything down and all I hearing from WHATWG is excuses, not reasons.

- John

[kaled]

Quoting WHATWG

No browser ever implemented all of HTML4... They all picked and chose the bits they thought were useful.

That may be true - so they are admitting HTML4 had crappy useless bits - that really bodes well for HTML(5)! So, what they are saying is that website designers cannot count on browsers implementing features?

Someone has lost the plot - maybe it's me but I don't think so. It still baffles me that client-side includes are allowed for images but not text. Something like <divx src="url"> would be trivial to implement and could be very useful, but the last time I looked no one involved in HTML standards was smart enough to figure this out.

Kaled.

[tedster]

WHATWG was formed because a significant number of members (including key browser makers) felt that the W3C had lost the plot. The two groupls mended their differences, but only after TWO YEARS, and the overall direction is now one that browser makers feel will make sense.

Every web author can write mark-up in the style that they prefer. The overall experience has been that valid (X)HTML on the web is extremely rare in every flavor. So this direction is one that browser makers can and will move forward with and support, without placing intense barriers in the way of the average web author.

In addition, the recommendation is getting extremely large mostly because it is a lot more ambitious:

1. There will be uniform error recovery recommendations. No more cross-browser differences!
2. There will eventually be standardized JavaScript APIs. This will enable more complex online applications

While many of us here may approach (X)HTML as a kind of code, this is far from the norm in the world. Incorrect code fails - whereas browsers have long tried to render invalid mark-up as best they can. Most web authors are very used to this situation and lazy about valid code. But if the browser makers had done it differently, the web would not have grown as fast as it did.

I see these new directions as being eminently practical rather than academically rigid - which is the direction the W3C was previously going. The real world issued a wake-up call.

[mattur]

Browsers implement *features* individually, as an ongoing process. Browsers do not implement whole *specifications* in one go. Just because a feature is in a spec does not mean, and never has meant, it is ready to be used by authors.

Example: Microsoft only added support for CSS2's display:table (1998) in IE8 (2009), but had already implemented other CSS2 features in previous versions of IE.

So nothing to worry about - this is the way it has always been :) - it's just changing the standards process to more accurately reflect what actually happens in reality.

[edited by: mattur at 2:10 am (utc) on Jan 24, 2011]

[kaled]

Incorrect code fails - whereas browsers have long tried to render invalid mark-up as best they can.

That's not strictly true, often code (javascript) works fine in IE but fails on other browsers. Most seasoned developers here know the rule that you write for Mozilla first and then test on IE (though I test continually on Firefox, IE and Opera when I'm doing anything).

There will be uniform error recovery recommendations.

Again, this doesn't scream smart to me, it screams dumb - yes dumb, I really do mean it. Instead of worrying about uniform error recovery they should suggest browsers report errors - that way they might actually get fixed!

it's just changing the standards process to more accurately reflect what actually happens in reality.

Alternatively, it's just letting lazy development teams off the hook and handing them a dirty great excuse to be complacent.
OR
it's just scrapping the concept of standards altogether - those setting them may as well vote themselves out of existence.

Both these views are just as valid as your statement.

Kaled.

[StoutFiles]

We don't do this with other languages so why should we do it with HTML?

"To get data out of a database you can use PHP5!" "Use CSS2 with that tag!"

I refer to the above as PHP and CSS, only when there are errors do I acknowledge versions. They SHOULD just call it HTML.

[xnavigator]

>What disgusts me is that like forever, XHTML being sent as text/html was "the way" to go

lol just look how source code for google is: view-source:http://www.google.com/

that's the standard... who cares about xhtml?
google doenst' even close <body> tag :D

[SuzyUK]

We don't do this with other languages so why should we do it with HTML?

Agreed!

It's pretty much been the case with CSS - CSS2.1 should never have been a 'version', and in fact I think it is now retrospectively properly known as CSS2. There were always moving changes in the 2/2.1 spec, CSS3 is just a convention/buzz-word - it just means it's still CSS nothing new to actual error recovery or the basics - but it's now modularised ready for the introduction of new functionality - some parts are implemented/supported some aren't. I think that's probably the intent with HTML5, as someone else said it's too big to inplement all new things in one go, but a bit at a time is good for competition.

If it's any consolation I think, in hindsight, that this way helped the CSS cause, browsers did "compete" to provide support for the more popular/used parts and use cases were tested properly and patched (IOW specs were written/changed live!) instead of theoretically. If certain browsers had not stepped up to bat and tried things, they would never have got done!

A living spec, cuts out the theory (arguments & bickering over who's right too) and gets on with the job quicker, if you like

don't know if HTML (5 or not) needed such a radical proclamation of that same methodology but I think that's it intention.. it should be good news for those that actually want it to start happening anytime soon.

[kaled]

So, what you are saying is...

HTML(5) has become so ludicrously overblown, it is unreasonable to expect browser writers to implement all of it, instead they should be encouraged to think of it as a pick-and-mix and just implements the bits they think are cool.

Can anyone offer up the name of a standards organisation that has suggested something similar. Where would we be if digital TV had gone this route, USB devices, HTTP, or TCP/IP, etc?

If this is a good idea, I'm living in the twilight zone.

Perhaps if HTML(5) has become so overblown, the answer is to cut it back to what is needed rather than simply keep adding useless features that no one is ever going to implement because no one is ever going to use because no one is going to implement it because they can still claim to be standards compliant without bothering.

When I was at university, the ultimate insult you could throw at a computer language was to say it was designed by a committee - it's so true, so very very true.

The only good thing you can say about this policy is, the browser manufactures will have to form their own standards organisation. Clearly, it can't happen a day too soon. In the same way that XHTML looks like vanishing, perhaps HTML5 will vanish in favour of HTML 4.5 - let's be realistic, there aren't really many new features that are truly needed - a sensible spec could be thrashed out in a few days.

Kaled.

[trillianjedi]

Well, as they say in their tagline:-

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

[Sgt_Kickaxe]

Thank you for making browsers even less uniform than before, now kindly step away from the code.

[swa66]

Browsers implement *features* individually, as an ongoing process. Browsers do not implement whole *specifications* in one go. Just because a feature is in a spec does not mean, and never has meant, it is ready to be used by authors.

Agreed and that's what makes it SAD.

A standard should state if you want to say your browser supports HTML5, you MUST do this, SHOULD do that, MAY do this, SHOULD NOT do that, and MUST NOT do that.

And then make the gray area as small as possible.

But alas the browser makers never got along, and letting them have a say over what is in the standard as a group will never solve it. Time for the people to take back the power to decide what's in the standard and kick the corporations out of the process.

So this direction is one that browser makers can and will move forward with and support, without placing intense barriers in the way of the average web author.

They place one gigantic hurdle: dumbing it down. Not what I was looking for -at all.

I was wondering if I should start to play with xhtml5. I think this is clear to me (x)html5 is dead (killed by the browser crafters). So, since they claim to process anything and everything -basically no guarantees-, I'll stick with xhtml1.0 (strict where possible, transitional if I have to).

Sure we can call it html and css in day to day language, but the files we create are in a specific version of the language, just like your php script is intended for a specific version, and just look at the doc it'll say a given functionality was added in version X and might be deprecated in version Y, or even removed in version Z.

[Robert Charlton]

I haven't been following the politics of this one, but I just chanced to see the homepage of the W3C site [w3.org...] ...and I'm getting the feeling that we're caught in the middle of a civil war. Or am I misinterpreting?

W3C Introduces an HTML5 Logo
18 January 2011

W3C unveiled today an HTML5 logo, a striking visual identity for the open web platform. W3C encourages early adopters to use HTML5 and to provide feedback to the W3C HTML Working Group as part of the standardization process....

The HTML5 logo and the page it's on is about as over the top as anything I've seen in quite a while. Sorry I can't reproduce the graphics here... you'll have to click the link....

http://www.w3.org/html/logo/ [w3.org]

Take Control — Your Web, Your Logo

An HTML5 Logo

It stands strong and true, resilient and universal as the markup you write. It shines as bright and as bold as the forward-thinking, dedicated web developers you are. It's the standard's standard, a pennant for progress. And it certainly doesn't use tables for layout.

We present an HTML5 logo.

Someone appears to be making a statement, and perhaps it's warranted, or perhaps....

So, I'm wondering how to match up the version of my validator with whatever version the current code happens to be.

[IanKelley]

XHTML

I never jumped on the XHTML bandwagon, it didn't improve anything so there was no reason to go back and change a lot of code. It was not as if original HTML was going to suddenly stop working in the foreseeable future.

The real world issued a wake-up call.

Exactly! The web is a work in progress. As developers we want perfect standards and strict interpretation because that's how programming languages work.

Well that and cross browser testing sucks.

But HTML has allowed the web to decide it's own fate, and go in unexpected directions, because implementation has been loose and dynamic.

Hacking is good. Who cares if tables weren't meant for layout? It was a great way to implement something that wasn't part of the "standard" at the time. Should we have waited for CSS?

We all knew (I would hope) that consumers were never going to use a browser that forced strict interpretation and thereby broke half of the web.

I guess I'm straying a little off topic... My point is that it really doesn't matter what the browser makers and standards bodies do. Developers will continue to come up with novel ways of accomplishing things, and browser makers will continue to try to render the largest possible percentage of pages in a way that looks good to their users.

Which is not to say that browser makers couldn't do a better job of implementing standards. They can, maybe even will, but making pages look like as much as possible like they were intended is always going to be the primary goal.

Instead of worrying about uniform error recovery they should suggest browsers report errors - that way they might actually get fixed!

You and I might like this idea, but the general public has no interest in it. Why should they? A web page is a user interface, not a development environment.

[g1smd]

Apart from using HTML 3.2 for a brief period in the very early days I have never seen a need to code in anything other than HTML 4.01, and I still don't. The XHTML wars were a distraction that I managed to completely avoid. I had recently started thinking about HTML 5, but this new development has made me scratch it off the list of things to do in 2011.

[mattur]

Thank you for making browsers even less uniform than before...

The WHATWG spec precisely describes how to parse HTML. No previous HTML spec has done this. So browsers now have a target to converge upon. It won't happen overnight, but over time it will gradually make the web a more consistent and reliable platform to develop on.

One reason why previous W3C HTML specs were short is they left out most of the detail needed to achieve interoperability. The WHATWG have done something awesome: they reverse engineered how browsers currently parse HTML and documented it. They also spec'd undocumented but essential parts of the platform like document.write, innerHTML, Window Object, XmlHTTPRequest, <canvas> etc.

This "HTML" parsing algorithm is used in the new HTML validator. Firefox 4 implements this exact parsing algorithm. Opera, Safari and Chrome are converging on it. And Microsoft are involved - and submitting test cases!

Browsers are adding new features at a faster rate than any time in web history. This is a great time!

[kaled]

You and I might like this idea, but the general public has no interest in it.

The general public has no interest in the W3C, WHATWG, HTML, HTTP, CGI or anything else - all they care about is does it work.

All I'm talking about is a flag in the status bar that indicates a rendering error (HTML or maybe CSS as well) that can be clicked for more information.

The purpose of any web standards organisation is to improve quality and uniformity. The idea that standardizing the handling of HTML errors is a good thing is plainly nuts - the message this sends out to web developers is "It doesn't matter if you write error-strewn code, the browsers will handle your errors in a standardized way, so your errors aren't really errors, they're just an alternative way of doing things."

Any standards organisation with this sort of attitude deserves one thing and one thing only - oblivion.

However, certain "errors" should be ignored for this purpose, for instance there is no point putting alt text on an image used to implement round-corners, etc. Also, other "errors" should be made legal, for instance, placing <noscript> in the <head> should be legal. Indeed, all the silly rules that serve no purpose should be scrapped - and there are enough of those for a new thread.

Standards organisations are not supposed to "go with flow" they are supposed to set the direction of flow - in a sensible direction. However, both HTML and CSS have suffered very badly from having idiots in charge of standards - for instance, why can you not define symbolic constants something like #define myColor = purple in CSS. This would be useful and trivially simple and has doubtless been proposed many times but some dumbo somewhere has said "No, no, no, that would sacrilege for (some pathetic reason)".

Kaled.

[mattur]

The idea that standardizing the handling of HTML errors is a good thing is plainly nuts...

As Chris Lilley from W3C put it:

"99.99999% of the Web was invalid HTML. W3C pretended that didn’t exist. This isn’t a workable solution."
[w3.org...]

Why can you not define symbolic constants something like #define myColor = purple in CSS...

It's coming: [xanthir.com...]

[SuzyUK]

The bruhaha over the HTML5 Logo [w3.org] is/was somewhat of a hornets nest (I don't like the CSS3 icon in "related technolgies" bit, either ;)) but reading the outcry after the event helped explain (to me anyhow) how the W3C position over the "5" differs from WHATWG - @Robert Charlton: not sure if that's what you were referring to with your "civil war", perhaps it was just the military style of the logo hehe but I was initially confused too.

The WHATWG is the group who are dropping the "5" as they will always be working on and promoting HTML as it evolves, this makes sense for it to become a Living Standard [whatwg.org].. the W3C are going to take "snapshots" at points in the development, maybe that's so the browsers can 'officially' benchmark against something, or validators have something to validate to. These snapshots will still be released under the HTML5 "set of technolgies"; toungue in cheek reference to their earlier faux pas whereby they inferred HTML5 actually encompassed CSS, SVG, WOFF etc. - Under that shiny new logo, which may not even be final yet, authors are encourage to bend/shape it any way they like. Which is to say it will be likely the more implemented and tested parts of the living standard which would get included in the W3C snapshots, it will not, and shouldn't, stop browsers using the WHATWG standards to introduce these features so they can be used and tested.

The Logo is to be credited to the W3C and Tantek's suggestion about how to reword some of the FAQ has been listened to and they've changed already. It originally sounded like (some say the military style badges) suggest HTML5 is the 'be all and end all', when in reality it's only the cornerstone that all these other, separate, technologies are related to.

>>re: faux pas
it has now been corrected, and it was kinda like the next part of this reply - CSS3 is not part of HTML5, so CSS discussion in this thread is probably OT :o

<OT>

"IT's coming"

.. hopefully not as a x-browser rec though. Browser specific applications maybe, or some sort of preprocessor/API - @kaled, CSS Variables & related [webmasterworld.com]. post #2 leads to an older thread where it was discussed as it pertains to the CSS specs. The technology to do this already exists.</OT>

[kaled]

I did not suggest CSS variables I suggested macro-like constants. Frankly, this should have been in the first draft spec of CSS 0.1 just as client-side inclusion of text should have been in the first iteration of HTML.

There is little or no point creating a "living standard" without versioning. If a living standard is desirable, then start at 4.1 and increment it every six months. Consider this...

The only sensible way for designers to make use of new features in a "living standard" is if browsers declare their capabilities when making http requests. Without version numbers, this necessarily becomes more and more complicated as new features are added. I suppose you could use some sort of individual feature test (client-side) a bit like <noscript> but this would need some sort of <else> construction and suddenly it starts to get hideous.

Incidentally, if snapshots are going to be taken, what is the plan for identifying these snapshots - using dates, silly names (like Chicago) or wait for it, I have a brilliant idea, let's identify the snaphots with numbers - gosh, it's so simple really. Why hasn't anyone thought of this before? DOHHHHHHHHHHHH.

Kaled.

[Robert Charlton]

@Robert Charlton: not sure if that's what you were referring to with your "civil war", perhaps it was just the military style of the logo hehe but I was initially confused too.

It was the shield and the sergeant's stripes and some of the material I've quoted here.

From an outsider's point of view... and I should emphasize that I haven't followed the personalities of these groups... I'm still confused. I'm seeing what appears to be the splintering of an alliance, with one side appearing to be desperately flashing badges and ranting bombastic rhetoric, and the other side appearing to be snearing back and saying: "Badges, we don't need no stinking' badges"... [youtube.com...] ...Can't tell how much, if anything, from either side is intended to be in good fun.

Now, looking at the W3C logo page [w3.org] more deeply, I'm seeing that the W3C is suggesting tools to build custom badges for features implemented (perhaps instead of version numbers?). Do I detect some heavy irony here, or, again, are they really serious? Who cares about logos on what's been implemented? That's like: "This site works better in Netscape 4".

The whole point, I would think, is that we have a uniform and overall set of specifications at any one time... easily identified (yes, by number)... to which all browser makers and developers adhere, so we have some expectation of sites working uniformly in all current browsers for a reasonable amount of time.

Sorry to be dense, but is this [w3.org] irony or have these guys flipped?...

Badge Builder 5000
You're seconds away from your own stunning, customized badge. Fire up the Badge Builder 5000.

What the tech?
Build a logo that shows off what you use.

[kaled]

That page does look read like something from a Paul Verhoeven movie (think Robocop and Starship Troopers).

Kaled.

[swa66]

However, both HTML and CSS have suffered very badly from having idiots in charge of standards - for instance, why can you not define symbolic constants something like #define myColor = purple in CSS. This would be useful and trivially simple and has doubtless been proposed many times but some dumbo somewhere has said "No, no, no, that would sacrilege for (some pathetic reason)".

I don't know those in charge of HTML and CSS from a standards point of view. But aside of these recent "dumbing it down" efforts I've been able to mostly find myself and gotten annoyed with the browser crafters that fail to properly adhere to standards they helped create themselves.

But I do know a few small things about CSS and the "pathetic reason" is that it is opposed to the philosophy, the strategy and the guidance of CSS and not
needed to those who understand CSS [As pointed out already by SuzyUK].

The day they add variables to the CSS standard, is the day when those in charge of the CSS standard have failed us [no doubt some browser crafter will add it sooner rather than later].