- From: Ben Ward <ben@ben-ward.co.uk>
- Date: Sat, 14 Apr 2007 12:40:16 +0100
- To: public-html@w3.org
On 13 Apr 2007, at 20:07, Chris Wilson wrote: >> Supporting >> it, in all its versions, is prohibitively expensive for anyone but >> Microsoft. >> > > Supporting all Office formats from all past versions is incredibly > expensive, period. Microsoft just already paid some of that cost. > And for me, that underlines the point of this non-versioned HTML concept. If you version HTML then you're imposing similar chaos onto a future UA development as a new word processor has with DOC and DOCX now. Yes, HTML has more specs than DOC but the quantity if unspecified behaviour will only increase with time if the document is versioned rather than fixed. As Ian says, people are writing content for the web to last forever. Of course that sounds grand, but having one, backward interoperable spec is the best way to serve content publishers. I have a question for Chris Wilson and other versioning advocates at this point: What if you're right? What if actually it is unsustainable to develop HTML in an evolutionary manner beyond HTML5? Maybe Ian Hickson and the WHATWG, bright as they are, have missed some critical facet that means we do need a discrete switch between revisions after all? What if you're right? How does that block this group from _attempting_ to build a better, evolutionary and backward compatible HTML? Why can we not approach this first new HTML with the complete and committed intent that it be evolutionary over HTML4 and that HTML6 will be evolutionary over HTML5? Why can't we try it this better way? You'll still get a new DOCTYPE <!DOCTYPE html> so IEs legacy features can be switched one last time if you guys really need it. And then, we try to make this work. In 5 years time people will think about a second iteration of the HTML-WG process; alterations and enhancements to HTML5. If you're right and HTML does need a version flag to be implementable, what stops us looking at this question again? If versioning really is required then to move from HTML5 to HTML6 you can provide evidence and argument based on experience of this model. And if you're right, then we can add a version flag in HTML6. I don't understand why we can't pursue the best development process for HTML non-versioned, evolutionary and come back to versions at HTML6 if for some reason it won't work. I think I'm missing the part where this is actually a problem _right now_? Regards, Ben (Apologies to Chris Wilson, who I accidentally sent this message to directly earlier this morning)
Received on Saturday, 14 April 2007 11:41:43 UTC