Ok, I thought the doctype was a declaration to the browsers what rules you were following, and that if you didn't follow those rules, things could break.
Nope. I mean, sure, that was the original idea: browsers would read the link to the DTD in the doctype and go look up the rules they needed to correctly parse the page. This was exactly the idea for the zombified XHTML2 spec. This was where you and I were going to be making our own tags and stuff. Hahaha. Which you can still do with XML of course...
Of course, imagine how much slower everything would be if all browsers had to go grab a set of parsing rules for every page they loaded. And now imagine one web site might run several different namespaces too. Lawlz. But everyone has high-speed internets now don't they? (sarcasm)
Which led me to believe that with the new doctype, the browsers will accept everything, and therefore, rather than versioning, the new recommendations will will not have rollouts to completion but additions (like new tags) will be updated gradually as the browsers accept them. Is that not right?
Well, yes and no. No, you can't make an old browser learn new tricks. IE5 sees the <!doctype html> as a full doctype (actually that doesn't even matter, IE5 doesn't have any concept of Quirks Mode or Doctypes much anyways... but IE6 does, and most other browsers since 6 do, even Firefox etc), but it doesn't mean or say anything about the rules.
As far as rules go with adding new things, all you can know is whether a particular version of a particular browser (again, this will suck hairy dirty monkey balls when Mozilla stops revealing version numbers won't it?) supports a particular feature. We pretty much have this now with CSS3.
If we need to know if someone supports, say, <header> tags (and what does support mean? I'll get to that), now you have to go look it up on some website like caniuse.com or quirksmode.org's compatibility tables. Some browsers will support it and some won't, meaning more and more tags (and attributes and CSS properties) you the developer have to decide who you're going to leave behind, or who you're going to bloat up your code with polyfills for, or whatever. So there, you're right: vendors decide when they think they have a correct implementation of something, and release either versions who later no longer fit the (changed) spec, or conform with the spec. So like remember when webkit and Opera implemented WebSQL? Mozilla and IE didn't. Later WebSQL was dropped. What does this mean? It means if Mozilla and IE ever had the possibility of being convinced to also support it, that possibility is long gone now. And eventually webkit and Opera may remove their support if it gets in the way of other new things or bloats the browser up too much.
Browsers only have to keep backwards compatibility with something they've shipped in the past that has been formally deprecated. Since HTML5 for example is not formally deprecating longdesc or table summary attribute for example, whatever support browsers might have had might just vanish in the next version. They are not required to support it, similar to all the things in the older specs that nobody or one vendor once supported maybe. Also part of the HTML5 idea of "insist on support of what browsers/authors/users already work with".
Support: With HTML5, it's lovley. Some browsers (well, here I guess I just mean IE) have an internal list of acceptable tags. Anything else you throw in there in angled brackets like <foo> which are not on that list, simply do not exist. They are not added to the DOM.
Then you get everyone else who doesn't know what the tag is: it's added to the DOM, but not part of their default stylesheet. Since browsers are sometimes picky about who's really (in HTML) an inline and who's a block (mostly IE tho :), this kinda sucks, but not so bad. So here's why we're taking all the new tags and setting them to display: block in our stylesheets, because most of these tags are meant to be block elements. Also, because browsers in real life often ignored the HTML4/XHTML1 rules about blocks and inlines anyway (you could always have inlines as direct children of forms and blockquotes, and you could most of the time get away with wrapping anchors around divs filled with stuff, and browsers did their best to figure out what that meant, and mostly figured it out quite well), HTML5 has thrown a lot of those rules out anyway. This, an example of HTML5 trying to be descriptive as well as proscriptive. They wanted to write a spec based on vendor implementations, rather than theoretical rules that didn't physically exist.
The last level of "support" we don't have yet: semantic meaning of the new tags. <header> means nothing to anyone yet, but the idea is that some day it will allow other software and machines to recognise what a document header is. Or what <time> means.
When the <time> element suddenly disappeared from the spec, no browser vendor had any intention to remove it.
However, so far as I know only one browser had even implemented it (Opera). Suppose, like WebSQL, it was permanently removed from the spec. This means the other vendors get to think about it. They can decide not to support it. After all, it's out, right? Opera, on the other hand, would be unlikely to remove it. Hixie wanted to instead use a broader, less useful <data> element. Suppose that had gone through, and Opera was sitting there with <time> elements with pubdate attributes while everyone else got hip with the jive and implemented <data> elements with no pubdate attribute? It would probably mean we as authors would not use <time>. (One of the arguments against removing time wasn't that it was actually supported anywhere, but that people who build blog and CMS systems (pretty much mostly Drupal and Wordpress in this case) had taken something from a Draft Spec and just added it because they thought it was useful. So in other words,
"SOMEONE TOOK A DRAFT THINGIE AND ADDED IT SO NOW WE CAN'T TAKE IT BACK OH NOES!"
This is something the spec writers are dealing with anyway. As vendors attempt to implement draft things (which they need to do at least to find out how well or not the new thingie works at all), people start running with it whether it's good or not, doable or not, causes a crapload of new problems or not. If enough people use it, you get <embed>, which is in the HTML5 spec because... everyone supports it. Lots and lots of sites use it. Leaving it out of the spec simply means there a popular HTML tag out there that has zero documentation. So long as browsers support it, people will use it, and there's nothing but a whiny nerdy validator message to tell them otherwise (and the kinds of people who use tags not in the spec are the same kinds of people who don't bother validating anyway, so...). HTML5 wants HTML completely documented.
Why I like vendor prefixes with CSS: the prefix means it's still experimental, and so when it turned out the rest of the world didn't implement something called
we could all safely stop using the
stuff we'd been using, and stick to