- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sat, 01 Aug 2009 19:07:20 -0700
- To: Shelley Powers <shelleyp@burningbird.net>
- Cc: John Foliot <jfoliot@stanford.edu>, 'Sam Ruby' <rubys@intertwingly.net>, 'HTML WG' <public-html@w3.org>, 'Manu Sporny' <msporny@digitalbazaar.com>, "'Michael(tm) Smith'" <mike@w3.org>, 'Ian Hickson' <ian@hixie.ch>
Hi Shelley, On Aug 1, 2009, at 6:38 PM, Shelley Powers wrote: > > This one interests me above and beyond summary, as I wrote about > recently[1]. > > There is no clear demarcation between deprecated and obsolete in > HTML 5, as there was in HTML 4. Because of this lack, we're left > with situations like summary, where we may want to replace the > element at a future time, but we want it to be a valid element, and > supported, until there is a replacement for its functionality, and > the element can be gracefully made obsolete. I think the HTML5 category of "obsolete but conforming" is closer in meaning to the HTML4 of "deprecated" than the HTML4 category of "obsolete". I think it matches really well what is desired for summary="" - the element is valid and supported. The main practical difference, compared to HTML4 deprecated, is a required warning from the validator. That makes it a bit stronger than HTML4's "deprecated". HTML5's "obsolete and nonconforming" is closer to HTML4 "obsolete". But it still requires implementation support, and still actually describes the features instead of merely listing, so it is not as strong as HTML4's "obsolete". As I explained to John, the hesitance to use the word "deprecated" is that it's widely seen as toothless. I hope this helps clarify how HTML5 handles deprecation and obsolescence. It's not quite the same as HTML4, but I think the categories still do what we need. Regards, Maciej
Received on Sunday, 2 August 2009 02:08:01 UTC