I just found out that all the HTML5 Twitter commotion was because of two thousand twenty two. Apparently Jeff Croft stopped reading right after he read “2022” which does not seem like a smart thing to do as not reading beyond a single point of disagreement is bound to lead to not understanding what someone was trying to say. (Which is exactly what happened.) Then again, Ian already mentioned browsers are shipping HTML5 features and authors are using HTML5 features before that point, so his rant seems misplaced. Fortunately Jeremy Keith replied with some insights.
(I blogged about this before. It bears repeating apparently.)
I don't think all the Twitter commotion was because of my blog post. Rather, I wrote my blog post in response to the Twitter commotion. It sounds like you and I are very much on the same page -- we both agree that it's ridiculous and silly to get bent out of shape over the 2022 date. Glad we agree. :)
Could be worse; it seems you stopped reading Jeff's post at the title. Which is a shame because he makes a few worthwhile points in there.
James, do you mean the part where he talked about "those of us who do real work in this industry"? Or the part where he said "I care about right fucking now"? Or the part where he said "Who fucking cares?" Or the part where he said "that’s fucking ridiculous"? Or the part where he said "I’ll be doing real work, on real websites, which have real users, for real clients"?
Damn, that was two minutes of my life I'll never get back.
Mark, I mean the part where Jeff questioned the wisdom of setting a timeline for HTML which is nearly as long as the history of HTML up to this point. This isn't a knock against the features in HTML 5, or against the browsers implementing them, but it is -- I think -- a useful criticism of the process; such a timeline, regardless of how quickly browsers will implement the drafts, doesn't seem like it could be either realistic or pragmatic.
The timeline was based on experience with CSS, of which CSS 2 after a decade is still not done, due to lack of testing and missing details in the specification, yet is quite widely supported. (Enough for authors to use it since, say, 2000.)
Anyway, if you feel it can happen faster, feel free to help out!
Personally, I'm not a fan of standards working groups. I've watched enough of them at work to know that it's just not my cup of tea, so I just lurk when I can stand it (so far HTML 5 hasn't been as bad as Atom was, but there's still time...). And I really do think this is a major PR disaster for HTML 5; the timeline really says nothing about the thing people genuinely care about -- "when can I use it" -- and instead resorts to (confusing to non-insiders) standards-body jargon to define an arbitrary date, 14 years in the future, on which any remaining spec lawyers who can motivate themselves to care will start receiving hints that they should shut up and go elsewhere, or else risk being murdered in their sleep so the thing can finally be pushed out the door.
Yes, I know that implementation plays a big part in this timeline and so "when can I use it" may not be a possibility. But even "past this date, Zeldman should start issuing battle calls to kick vendors in the pants for their implementation issues" would be helpful, and isn't something that's available.
James, since asking vendors for CSS 2.1 support works, why won't asking vendors to support HTML5 features work? (In fact, this is largely the reason browser vendors, including Microsoft, are implementing HTML5 features today.)
Anne, if asking vendors to support the spec works, why put a date on the timeline that's 14 years in the future? Why not -- as I suggested -- a date for "past this, anybody who's not properly implementing should be yelled at"? That date would be quite a bit sooner and is much more what people are concerned with.
Presumably because Ian wanted to provide a realistic answer for when it would actually reach W3C Recommendation. He gave a date for Candidate Recommendation (also known as Call for Implementations) as well though. (And Last Call, somewhere in 2009, when the specification should be more or less ready.)
My humor may not have been well-received (at least by you, Anne...others seemed to enjoy it), but what you're saying is exactly the point I was trying to make.
As clear as I can state it, the point is this: the 2022 means nothing. Because it means nothing, it's totally ridiculous and absurd for Ian to have ever mentioned it. It could only have caused confusion and dissatisfaction (which it did). There was nothing good that could have possibly come out of setting a 14-year timetable on a spec in this industry, regardless of if it actually "meant anything" or not. If it doesn't mean anything, why mention it?
The goal of my post was, in a humorous, over-the-top, absurdist kind of way, to show just how irrelevant the 2022 date is. It was to say to people, "stop paying attention to the mundane details of all these standards and specs and start using the cool stuff browser makers are implementing."
So really, I think we're on the same page. It's just that my lack of word-mincing rubbed you the wrong way (and I don't blame you for that...it rubs a lot of people the wrong way, especially those who haven't met me in person and don't realize it's just part of my sense of humor).
"The biggest problem I see with supporting eugenics is the bad name it has aquired, through being associated with the Nazi movement, for instance. I'll leave that problem up to the PR folk to solve." Ian Hickson, 2002
I think it doesn't matter when the recommendation stage is reached because browser vendors will ultimately do what they want anyway. All we can hope for is that they work towards compliance, even if there's no 100% fit across the board.
If we waited for everything to be completed before implementation we'd get nothing done, and vendors would be no different to M$ failing to implement CSS 2.1 just because the spec hadn't been completed in time for their browser. Waiting on a release candidate is no excuse to stagnate.