The <time> fiasco
By glazou on Saturday 5 November 2011, 15:26 - Standards - Permalink
And all rejoiced because <time> is back in HTML5... But one thing has to be said: <time> is back not because it was a bad technical decision to remove it but because the HTML WG decision policy and process were not formally observed. In other terms, it's a loophole in the original action of removing <time> that allowed it back. Good catch and well done Paul (sincerely), but everyone has to understand it does not say <time> will be back forever.
More generally, I think (and I said it during TPAC) that too often basing HTML decisions on metrics or here "traction" is bad. When Unicode added some exotic charsets to the standard, some of them were proposed and supported by only one person, and no user of that writing script was in the consortium itself. Metrics ? Bah, the users of that writing script were not on the Web yet ! Traction ? One person. Let's discuss a11y too : just a fraction of web users need a11y features but these features are tremendously important to them. Among HTML spec developers, only a fraction really understand and propose a11y features, only a fraction of users need the features. Who said metrics, who said traction?
I have another example : the INS and DEL elements. They were introduced in HTML4 for visual modification marks. I was there, in the HTML WG. They can't cover all the cases Visual Modification Marks need, all editing environment authors know it. As a matter of fact, Microsoft Word is based on markup and CSS since the end of the 90's and AFAIK has never used INS and DEL because it's impossible. It uses attributes. So I proposed to make the current ins and del elements obsolete and switch to attributes. Rejected. Keeping a feature that does not work and will never work as intended is apparently better than making a better feature in the right way. Just so you know, this problem is now 20 years old. I clearly remember discussing Visual Modification Marks in markup-based editors with Jean Paoli and Vincent Quint in the first months of 1992 (yes, nineteen ninety two) and it was already clear that elements were not meeting the requirements. It was also discussed with Microsoft folks during the Web conference in Boston in 1995. The WHATWG/HTMLWG inability to deal with the accumulated experience in the marked-up world between 1986 (SGML release) and now is sometimes astonishing. Here, in the case of INS/DEL, metrics is zilch since nobody implements INS/DEL seriously. Traction? Right, implementors of Visual Modification Marks don't send feedback any more about that (I'm the only who still does it) because they have tried hard and dropped the case, relying on proprietary implementations. But now that WebApps offer more and more online cloud-based editing tools based on HTML, we need Visual Modification Marks in a standard way. It is highly time to have a workable solution here, and when I mean workable I don't mean INS and DEL.
For one reverted <time> fiasco, how many unreverted ones below the radars or worse, above the radars (think longdesc)?
Comments
Daniel,
You had me convinced last Monday, but the question is, what/how do you see a functional replacement looking like? "They should fix it" is only a partial answer, the other half of that sentence is "... and they could do it like this:____". It's a whole lot easier to rally the troops when you actually have a proposed replacement to evaluate against.
"A" sucks, so we should have a "B" without defining or at least sketching out what "B" looks like makes it a whole lot harder to determine if "B" is actually better than "A". This is in fact the current situation with @longdesc - now that the "B" solutions are coming forward (i.e. use aria-describedby), we can show that these proposed replacements are actually not as good as the original @longdesc (despite @longdesc's flaws): the proposals do not meet all the use-cases, and have some significant technical barriers that cannot be overcome at the renderer (browser) level.
I would support a move that sought to replace INS and DEL with something better. However, I'm not sure what they should be replaced with, and I have used these elements in my hand-written code in the past, as have others, so until such time as they have functionally better replacements, I don't think you will succeed in getting them removed.
Peace out!