W3C home > Mailing lists > Public > public-html@w3.org > December 2009

Re: discussions of HTML6

From: Shelley Powers <shelley.just@gmail.com>
Date: Fri, 4 Dec 2009 13:28:13 -0600
Message-ID: <643cc0270912041128r6fae4793r96b7b4ab87e27880@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: David Singer <singer@apple.com>, HTMLWG WG <public-html@w3.org>
On Fri, Dec 4, 2009 at 1:22 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> 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.

Yes, and no. If this group has a mindset that this version of HTML is
just a stepping stone, we may not make the best decisions.

However, point taken, and I'll drop this thread.

> - 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:28:46 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:54 UTC