Re: discussions of HTML6

While this is an interesting discussion, I note the following:

- This Working Group is not presently chartered to do HTML6; our  
charter only encompasses one new version of HTML. Thus, specific  
discussion of what will be in it is not entirely in scope for this list.
- On the other hand, nearly every successful W3C technology has had  
multiple versions. It is probably a good assumption that any given W3C  
spec is unlikely to be the final version. Thus, in general, it is a  
good assumption that features we don't include in HTML5 can still be  
added in some future version.

Regards,
Maciej

On Dec 4, 2009, at 9:28 AM, David Singer wrote:

> 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 19:22:44 UTC