Re: discussions of HTML6

I disagree with you, mostly.

I have worked on 'kitchen sink' specifications, where they have tried to cover everything that everyone wants in the 'specification to end all specifications'.  It results in bloat.  You do have to decide to make a cut, and deal with some questions in a future revision, or you end up with Brooks' second-system effect <http://en.wikipedia.org/wiki/The_Mythical_Man-Month>.

What does make sense is to check; "in the next version, we think we will want to do something like X. Have we designed the current version so that X will be difficult?".  Surprisingly, the answer to this often results in more trimming of the current version so as to leave a 'cleaner field' for future work.  Designing on the assumption that there will *not* be a successor is a mistake.

I think the pragmatic attitude of the HTML5 effort, to focus designs supported by use cases, data, experiment, and adoption, is really helping here.

I agree that specifications (or rather, their artefacts) live forever;  look at the effort we are now putting into historic HTML compatibility.

On Dec 4, 2009, at 6:52 , Shelley Powers wrote:

> This is a general observation, based on discussions I've read in the
> IRCs, the WhatWG email list, and in this email list. I keep seeing a
> reference to HTML6 (and HTML7 and so on).
> 
> Specifications are not like applications.  There is no such thing as
> an old or out of date specification, if what it defined continues to
> work.
> 
> Specifications for something like HTML need to be extremely stable
> because it can take years to remove past mistakes. It's not like
> popping out a new version of gimp. It's not even like popping out a
> new operating system version, such as Snow Leopard or Windows 7. It
> should be more like putting out a new version of the Internet
> Protocol: something that's fundamental to the web, generating many
> dependencies, and extremely significant expense and time when changed.
> 
> When we make statements such as "Oh, we can put that off to HTML6", or
> "If this doesn't work, we'll just pull it in HTML6", what we doing, in
> effect, is signaling this group's failure. Either we're trying to
> include too much in the umbrella term of "HTML", including application
> specific material, which is very volatile; or we're not dealing with
> issues correctly, or facing problems and disconnects directly.
> 
> Regardless, any mention of HTML6 in this group should be treated as an
> admission of failure on the part of this group.
> 
> We should be looking at HTML5, as an entity that can meet the needs
> for a web page markup, and associate DOM, both now, and in the future.
> 
> Shelley
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Friday, 4 December 2009 17:29:04 UTC