W3C home > Mailing lists > Public > public-html@w3.org > October 2012

Re: [HTMLWG] CfC: Adopt "Plan 2014" and make some specific related decisions

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Thu, 25 Oct 2012 11:42:42 +0100
Message-ID: <CA+ri+Vk=TU8HR5MXKMNNCWW=UVC4DmK0VGhAu6JAnS2v1r3xbA@mail.gmail.com>
To: Robin Berjon <robin@w3.org>
Cc: Jonas Sicking <jonas@sicking.cc>, Sam Ruby <rubys@intertwingly.net>, public-html@w3.org
Hi Robin,

An issue with forbidding of the use of the term HTML in the title is we
already have the HTML living standard which includes new, or unbaked or
unimplemented features, which receive the "HTML"  imprimatur many of which
are in HTML5 today.

I don't see why that if a new feature is specced and it starts to progress
through the HTML WG process it cannot use the term. If implementers are
unwilling to implement they can speak up and the spec will not go anywhere
(useful). Or if they will consider implementation, but have technical
feedback they can provide it and work with the editor(s) to address


On 25 October 2012 11:24, Robin Berjon <robin@w3.org> wrote:

> On 19/10/2012 09:47 , Jonas Sicking wrote:
>> A better solution is in my opinion for extension specs to carry their
>> own weight without relying on branding. This can be accomplished by
>> simply being careful about what we choose to put in the status section
>> of the drafts. So for example clearly stating that it's not a HTML WG
>> draft. And stating that though its published by W3C as a extension to
>> HTML, it's not actually part of HTML and might never be so.
>> That said, I really like the direction that the original proposal in
>> this thread takes.
>> The HTML spec has gotten so big that it carries its own momentum. That
>> means thar whatever goes into it will be carried by the HTML momentum
>> rather than its technical strength.
>> By making use of extension specs we can instead let the market decide
>> what makes it and what doesn't. Which I think is a great idea.
>> But in order for that idea to work we need to ensure that the language
>> in the drafts are clear enough that it actually is the technical
>> contents of the draft that gives it momentum, not association,
>> misunderstood or otherwise, with the HTML WG.
> I very much agree with your problem statement, but I have a slight concern
> with your proposal in the last paragraph above. Having "language in the
> drafts" that is "clear enough" could be addressed by having a paragraph
> buried in the SotD stating that this draft is not endorsed, shouldn't be
> considered as anything other than work in progress, etc. As it happens, we
> already have such text and it's effectively useless  making it stronger
> will just make for longer boilerplate to skip.
> It should be possible for the HTML WG to be associated with extension
> specs, simply because it should be possible for the HTML WG to produce some
> (in fact, it wouldn't hurt if that were the default mode of operation).
> But one way in which we can try to be crystal clear about a spec's status
> is through its title. I don't necessarily want to bikeshed this to death,
> but perhaps your concerns could be at least partially addressed through the
> requirement that extension specs, at least until such a time as they have
> gathered momentum of their own, do not ever make use of "HTML" or "HTML5"
> in their title. So you'd get "The <minitel> element" rather than "HTML5
> Minitel". This could be further reinforced as "Proposed Extension: The
> <minitel> element" or some such.
> --
> Robin Berjon - http://berjon.com/ - @robinberjon

Received on Thursday, 25 October 2012 10:43:50 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:28 UTC