Re: discussions of HTML6

On Fri, Dec 4, 2009 at 11:28 AM, David Singer <singer@apple.com> 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>.
>

I'm not sure that we can, on one hand, include all that we've included
in the current HTML specification, and then say we need to plan on
HTML6 because we're concerned about "bloat".

What we need to do, is create a specification that has the ability to
grow in the future without having to necessarily be dependent on
versions. We may not make it, we probably won't make it, but we're
counting on the next version of HTML a little too much. We especially
shouldn't count on a new version, just to clean up the messes we make
with this one. Or as a way of pushing off tough decisions.

> 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.
>

If we focused on building in clean extensibility than we don't
necessarily plan for what we're going to include in future versions of
HTML.

Unfortunately, HTML5 doesn't have a mechanism for clean extensibility
at this moment (and no, data-* is not "extensibility").

If we plan a version of HTML that doesn't include application
implementation details, we're definitely ensuring that HTML5 isn't
obsolete as soon as it is released.

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

No, I've not seen it. Folks put in use cases for metadata, and we got
Microdata. Yet Ian has said that none of the people who submitted use
cases for metadata have been happy with the result. So, no, we're not
depending on use cases. Or not working with the community that submits
use cases.

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

Yes, and that's why it's important that we don't put things into HTML5
that we're really not confident about, or that don't have healthy
community support.

Shelley
> 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:07:05 UTC