^I think the what-does-browser-x-support is going to go to object or feature detection. Like we do in Javascript.
I think that dropping the version number publically is a good marketing. Somebody who needs a site built won’t know or care if you do 4.01 or 5. I just put I know HTML on my resume.
I think on backend, dropping the version number is a huge mistake, for the reasons people stated above. I only like the doctype simplification because I don’t always remember the path for the doctype. But by simplifying it, are we adopting the stricter version? I don’t know the hardcore differences between the two, but can see things getting very ugly.
Oh wow. I do think we should have some sort of buzz word, at least amongst ourselves, to differentiate it, but I also like being able to emphasize that it’s MORE than just a buzz word. Like how there’s sites using CSS for layouts and older sites using tables for layouts - they’re both HTML but with different methods. So what’s the big thing with HTML 5? Those developer-created tags, right? (among other things…) Maybe if we need to differentiate we could call it rich-tag HTML. OR we can call it FRED, I’m cool with that too. 
I’d go with FRED. But it needs to stand for something. Fashionable Really Excellent Document is my suggestion.
From the marketing standpoint, it makes sense to drop it. From the technical standpoint, you need to recognize the limitations of browsers in relation to the version of HTML and CSS you are using, so it’s important to retain the version numbering.
It’s not “just” HTML, but maybe the hype over the new version was blown a bit out of proportion.
I’d go with FRED. But it needs to stand for something. Fashionable Really Excellent Document is my suggestion.
To reduce confusion, we should just call it Bruce.
And to unite the concepts:
Bruce Lawson on The Zen of HTML
Well worth watching for those of us who haven’t been keeping up.
Yes but at the current rate of progress Fred (or HTML5 as it used to be known) is at least 15 years away from becoming a standard - or at least it was before the name change as now with it bening less clearly defined as to what exactly it is supposed to be you can probably add a lot more years onto that.
Anyway since you need all browsers to actually support the new standard before it will be really usable it will take time after it becomes a standard for it to become useful. That means that since IE9 doesn’t fully support the new standard which doesn’t yet exist that IE9 will also be long gone before the new standard becomes relevant - by which time many will have switched to XHTML and HTML itself will be close to dying out.
With XHTML only needing IE8 to die out while the new Fred (or HTML5 or whatever you want to call it) will also require IE9 and possibly IE15 to die out before it will be usable it is fairly obvious which of the standards will be usable first.
Of course the other consideration is that what they are actually suggesting with HTML - to modularise the extra parts so that they can be progressively implemented - is what XHTML was created in order to handle in the first place. You simply combine the doctypes for the part of the language your page expects to use and that defines the standard that the page is expected to comply with. Of course it would be easier if the browsers were to actually use the doctyle to define how they interpret the tags rather than using their own internal equivalent.
Yes and no. Because of the drip-feed nature of new HTML and CSS features, there are a lot of browsers of various colours and flavours that support some features within a standard but not all of them. They might support many but not all features of CSS2, and a few features of CSS3. They might support some features of HTML5 but not others. To that extent, it is of limited use to say that the browser only supports HTML4.01 and CSS2, because it does more than that. It is more useful to developers to know which features each browser version supports.
That seems the crux of it to me. We tend not to ask if IE does or doesn’t support CSS2, because you could say yes or no to that. We really talk about what aspects/features of CSS IE supports, and we will probably end up doing the same with HTML. One supports canvas, another doesn’t, for example …
Fred it is.
Wow, you guys really have so much time to discuss about this uninteresting html version-ing topic? The current browsers from the past till now supports HTML and guess what?? The new modern browsers will support…HTML!
Most people are still using HTML 3.2 (even though many of them try to pretend that they are transitioning to HTML 4) so whatever the next version of HTML is called will not matter. What is important is knowing what particular HTML tags and attributes a particular browser supports and that is what the version numbering was for - the original WWW browser supports HTML but doesn’t understand many of the tags used today.
It is unfortunate that they are now trying to create a version of HTML along the same lines as had already been created with XHTML 2 - a modular approach to adding new features to the language.
I will also go with Fred.
This is a freaking joke. I will wait till XHTML 2.0 is released.
Wasn’t XHTML2 dropped in favour of HTML5?
So I hear, which is a huge mistake. What was the point of having XHTML 1.0? Just to drop XHTML all-together years later? The W3C is filled with a bunch of idiots.
Maybe it was too strict, or maybe it was IE’s fault. But felgall’s comments above are interesting too.
I think that this change is an unneccessary waste of time both for the group and the users
XHTML hasn’t been dropped … XHTML5 is being developed in parallel with HTML5, and uses the same code elements but reformulated to be XML compatible.
The reason that XHTML 2 has been dropped is because it was a joke. It was completely incompatible with any other version of (X)HTML, so developers – authors and software providers – would have had a much bigger learning curve. By using the same feature base and language as the latest version of HTML, XHTML5 stands a much better chance of adoption, because it doesn’t require anything dramatically different. Compare that with the complete language fork that XHTML2 would have given us, and it’s clear why XHTML2 was never going anywhere other than in the bin.