Shared publicly  - 
You really have to love the W3C.

A few weeks ago, I replaced <time> with <data>. We got feedback from many people saying that there were use cases that <data> didn't handle, and requesting <time> be left in the spec. It turns out what people were asking for was not quite the old <time> element, it was more like a variant of <data> that was specifically for <time>. (The old <time> was specified as doing locale-specific rendering, had a more or less useless API, and only supported a small set of data and time syntaxes.) Tantek made a proposal for how to handle these use cases, which I intend to add to the spec ("the <time> element is dead, long live the <time> element"). Unfortunately, since last week was the W3C TPAC meeting, and this week has seen a combination of unexpected family matters and work meetings, I haven't yet gotten around to making that change.

In the meantime, the HTML WG chairs announced that the <time> change had to be reverted, giving a deadline of a few days (during none of which was I near a text editor). I spoke to one of them in person suggesting that we should just add the new <time> element as Tantek proposes, and was told to e-mail him privately, which I did as soon as I got back to work. The response? They decided to direct +Michael Smith to hand-revert the changes, causing make-work for him and me (the CVS conflicts are going to take hours to resolve), and have directed me not to fix the <time> issue at all.

Way to go team! It sure is nice working in such a pleasant and cooperative environment where everyone clearly has the best interests of the Web at heart.
Julian Reschke's profile photoFormer Gavin Carothers's profile photobrad dunbar's profile photoChad LaFarge's profile photo
You could have replied to the mail asking for the revert. You could have joined the telco. You chose not to.
Of course, if you hadn't ignored the feedback in making that change in the first place, no one would have had to do anything about it.
+Gavin Carothers The <time> that was removed isn't the <time> that people want, though, so I don't think that's a good argument. Volume of feedback isn't what matters, it's the use cases. The use cases Tantek presents in his proposal weren't detailed in the original feedback in a way that really argued for either keeping <time> nor introducing a new <time>. Now that they have been provided, I think it makes a lot of sense to support this new <time> element.
+Julian Reschke You are misinformed; I in fact discussed the issue in person with the chairs within hours of their e-mail and acted exactly as I was advised to act in as prompt a manner as I was able to.
+Ian Hickson Well, they asked for a revert, and you did not revert. That's what I can see. Also, whining about Mike now having to deal with the consequences is absurd; it was your choice to make life harder for him. How about finally doing the revert, so Mike doesn't have to deal with it?
You are commenting from a position of incomplete information.
Yeah, simply replacing <time> with <data> was clearly the wrong thing to do — based on the use cases Tantek has since documented, it's clear to me that it needs to be replaced by both <data> and a new <time> element, as Tantek describes.
The main use case is software (e.g. library scripts or data analysis tools) that are doing context-free searches for years, durations, months, time zones and other similar time-related data that would not, without the semantic of a <time> element, be unambiguously detectable. (Years, for example, look the same as arbitrary integers without some minimal context.) The old <time> element didn't help with this (all the formats it allowed are quite detectable even without the context of an element). There's evidence that time-related data types are widely published, so it makes sense to have a <data> "subclass" specifically for this kind of data; through careful selection of the kinds of formats we allow it to be used with, we can get away with only introducing one element for a number of different formats. Going forward I expect we'll find other formats that are also widely published and would benefit from the same disambiguation relative to <data>, though at this stage it's probably too early to tell which formats those are.

It's quite possible that this use case has been documented for a long time, but if so I haven't yet come across them in bugs or e-mail. (I don't actively trawl the wiki for feedback, and the wiki pages in question are full of other use cases that mostly do not need either the old or the new <time> element, e.g. publishing use cases without a corresponding consumer, microdata and microformats use cases, etc, so even if I had looked at those pages I would likely have missed the important cases.)
You actually did comment "-1" on Tantek's wiki page, but anyway... if <time> is a "subclass" of <data>, will it also use value=""? datetime="" is a bit mismatched for years or durations.
I actually don't care about the time element that much. What is clear is that there is a communication issue between WHATWG and W3C and it needs to be resolved ASAP as it is doing nothing but harm to HTML5.

We can't have a beast with two heads running the development of the HTML5 spec and I don't like the idea of W3C issuing an order to revert (and then taking action to revert) when the appropriate conversations have not taken place.
+Steve Fenton The HTML WG asked for a revert because the appropriate conversations have not taken place. Reverting the change doesn't imply that no changes will be made, it just means that they'll be made after these conversations have taken place.
+Daniel Glazman Are you saying the W3C is not a pleasant and cooperative environment where everyone clearly has the best interests of the Web at heart?
kelv i
+Ian Hickson I see this whole <time> debate as a WHATWG success. The correct outcome has been arrived at (& relatively speedily), even if it seems that the usually tectonically paced W3C seems to have become impatient… weird.
kelv i
+Julian Reschke Yes! Where's the huge failure here? +Ian Hickson moved with conviction in what he believed, the community as a whole rallied against that and it was very quickly overturned and is now heading in a direction whereby the <time> element has support encapsulating more common use cases… is that your definition of failure?

And I couldn't care less about some poor sod having to maintain CVS (although I feel their pain), but in a few months time nobody will remember that.
+Kelvin Jones The failure is that we have a needless fork, a WHATWG version of the spec that's out of sync with what the community has decided (sort of limbo state), and somebody having to maintain the fork (and whether this is CVS or something else is totally irrelevant here). All of this could be fixed by Ian actually doing executing the revert in this spec, which probably is a matter of five minutes. He doesn't, so he and only he is to blame for the confusion and additional work this is causing.
+Daniel Glazman: "Major players" have been complaining about the WHATWG since literally before it was conceived of — way back in 2003 we had big companies like IBM complaining that what eventually became the WHATWG, then HTML5, and now the HTML standard, was a huge mistake and the wrong direction for the Web and so forth. Nothing new there.

Re what we were talking about at TPAC, I stand by what I said (though your specific quotes are misleadingly out of context). Specs don't matter, except as a means to an end. What matters is interoperability. Doesn't have to just be browsers — the same applies in all standards. Specifications are mere tools to obtain interoperability. They literally do nothing useful to the world at large other than that. If there was a way to get multiple vendors to interoperate (whether this be browser vendors, screw manufacturers, wifi transceiver merchants, or anything else) that involved less work than having to write a specification, then that would be fantastic.

Third party tools are important — indeed, all tools are third party tools, including browsers. However, some implementations are more important than others. This isn't a value judgement, it's a market reality: if a browser with 80% market share has behaviour A, and a small data analysis tool with 3 users has behaviour B, and the specification requires behaviour C, then the reality is that the spec and the data analysis tool are wrong, and the browser wins. The same applies to everything in standards. If a screw manufacturer makes 99% of the world's "Type 47ST" screws, but they use a diameter of 6mm while the standard requires a diameter of 5mm, then the reality is that "Type 47ST" screws have a diameter of 6mm, and the standard is wrong, as are any tools made to the 5mm standard.

De facto standards > de jure standards. This is the most important lesson any spec editor can learn.

The Web is, and should be, driven by technical merit, not consensus. The W3C pretends otherwise, and wastes a lot of time for it. The WHATWG does not.
And Ian, who defines the merit?

Only you? A handful of people who you've selected, since that's the only membership at WHATWG?

Do those with accessibility issues have a chance to define merit?

How about web authors and developers--can we define what is of technical merit?

Third party tool developers, are they going to be given a chance to have a say in what's technical merit?

I agree with you: the web should be driven by technical merit. Where I profoundly disagree with you is the fact that the pool of people who you deem to have sufficient merit to determine the technical merit of the web is breathtakingly small and overwhelmingly homogeneous.
You people all need to stop polarizing the debate. You know why I shared that link and if you don't, you need to re-read this entire thread.
+Shelley Powers: Regardless of who you and I would like to have defining the merit, the reality is that the decision is made by the people writing the software that is widely used. We can pretend otherwise, but then we get things like XForms — technically far superior to anything we have on the Web today, and yet ultimately not widely used.
+Ian Hickson You're saying, in effect, that only the people currently involved in developing a handful of browsers should have a say in the future of the web. That is an incredibly narrow view of the web that inhibits rather than encourages the web's growth.

It also disregards the third party developers, the assistive device developers, and others who develop tools based on the specifications that are created in the W3C. To ignore them is to define the web as being a closed environment created by web browser developers for web browser developers...and the rest of us can either tag along, or shut up.

We can't see the future clearly enough that we can arrogantly close the door on innovation by limiting web specification development solely to "what works for the browser companies today".

Tim Berners-Lee did not envision the small world you seem to want to create, when he gave us the tools to start building something we couldn't even imagine existing 25 years ago. I don't think I've ever heard him embrace such finite boundaries as, "whatever works for today's browser companies".

Seriously, Ian: you need to think outside the box.
+Johannes Gorset and +Ian Hickson Bunk.

I'll tell you who really defines the standards...the people that use them.

Browser developers can get into their little self serving circle and ignore the vast number of web developers, designers, accessibility experts, and users, but in the end we will have the final say about the web.

Just ask Google what happens when it rolls out all sorts of cool new stuff...and no one shows up to play. How many "cool" projects have bit the dust? I can't remember half of them. Even Google+ hasn't been the big challenge to Facebook the company thought.

And I don't expect it ever will.

That's because Google closes itself off, and rolls out technology it thinks we want--rather than sitting down and listening to us and discovering what we really want. The company's hubris is breathtaking.

The same has happened and will happen with web standards.

No matter how much you try to control how people use HTML5 (or WebVTT or any other spec), people will use them the way they want to use them. Or not use them.

I expect the hidden attribute to quickly die. Point of fact, I expect half of the new HTML5 elements to die--and most to be misused because people really don't give a darn what Ian and the WHATWG folks and a handful of browser developers think we should want.

The browser developers had their chance. People did join the W3C HTML WG wanting to be involved. People did try...are still trying. But the browser folks don't want to listen to us.

Fine. Just don't expect us to listen to you in the future. And certainly don't expect us to think and do what you expect us to.

So, I beg to differ with you, Ian. Your reality really isn't the reality, after all.
So just remind me why WHATWG has anything at all to do with W3C? I thought that WHATWG's raison d'être was that the W3C had completely lost the plot ...