- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 2 May 2007 14:01:21 -0700
- To: Dave Raggett <dsr@w3.org>
- Cc: Elliott Sprehn <esprehn@gmail.com>, Lee Roberts <lee_roberts@roserockdesign.com>, www-html@w3.org, public-html@w3.org
On May 2, 2007, at 11:06 AM, Dave Raggett wrote: > > On Wed, 2 May 2007, Elliott Sprehn wrote: > >> On May 2, 2007, at 12:58 PM, Lee Roberts wrote: >> >>> [...] >>> 1. How long do we need to continue to support deprecated tags? >>> HTML4 attempted to clean house by deprecating tags in lieu of CSS >>> abilities. >> >> Forever. The specification must contain details on how to process >> the deprecated tags so that UAs of the future will know how to >> process old documents. > > I agree with documenting deprecated tags for future UAs but don't > see that that necessarily means this has to be done in the same > specification. It would be a lot cleaner to have one specification > for just the current tags and separate specifications for > deprecated/obsolete tags. It sounds to me like this would be more work for the editors, with little practical benefit. I'd rather not ask them to do the extra work of writing multiple specs, where massive cross-references will be needed. >>> 4. Can't we start by cleaning up the HTML4.x and XHTML1.x >>> standards? After we clean that up, I think we could then discuss >>> new elements such as term, canvas, and others. >> >> Is there a problem with accepting the WHATWG HTML5 specification >> as a starting point? A lot of this work was already done. > > It would indeed be a shame to throw that work away, but that is not > in itself a reason for having one giant spec that covers all > current and past features, worts and all. > > It would be a lot more manageable if we were to proceed with > several smaller specs. This would be easier on people from outside > of the HTML WG, and easier when it comes to moving through the > various stages of the W3C Process. Having multiple smaller specs is also extra work for the editors, since many cross-references will likely be needed. If we can find self-contained sections where there would be a real benefit to breaking it out (for example, it's intended to be used with other languages besides HTML) and we can find the manpower to move that section forward, it might make sense. But breaking things up arbitrarily likely won't be helpful. Regards, Maciej
Received on Wednesday, 2 May 2007 21:01:34 UTC