Re: A bit of electioneering on the <canvas> charter issue

On Nov 20, 2007, at 6:11 AM, Sam Ruby wrote:

> Maciej Stachowiak wrote:
>> On Nov 19, 2007, at 11:58 AM, Sam Ruby wrote:
>>> Maciej Stachowiak wrote:
>>>> We should interpret the charter as covering all reasonable  
>>>> application and document features. Otherwise, we will have to  
>>>> recharter every time someone realizes we are missing important  
>>>> functionality that doesn't already have a detailed line item in  
>>>> the charter.
>>>
>>> Such a charter interpretation creates a good chance of HTML5 never  
>>> being complete.  There are a lot of ideas that somebody out there  
>>> considers reasonable.  And next year, there will be more.
>> At some point, HTML5 will be complete because we agree to declare  
>> feature freeze and defer additional good ideas to HTML6. HTML more  
>> generally will likely never be complete. Note that most charters do  
>> not specifically enumerate all expected features.
>
> A lot depends on how the term "we" is defined.
>
> A consistent policy of "You want that feature?  Go change the  
> charter. Good luck with that" works wonders.

I would imagine at some point we take a working group vote to declare  
a feature freeze date, after which point features can only be added  
through some extraordinary process.

That or we agree on a requirements document that is separate from both  
the charter and the spec, and feature freeze occurs once all items in  
the requirements document are in the spec. New features could only be  
added by being added to the requirements doc. This appears to be what  
SVG WG did, and it gives much of the same control as the charter,  
without the huge risk of rechartering.

> If nearly everybody agrees, magical things can happen.  In this  
> specific case, if the measure of "nearly" includes market share as a  
> factor, proceeding without modifying the charter is tantamount to  
> proceeding at risk and depending the future whims of one particular  
> vendor.  Note: I obviously have no special insight into the  
> potential future votes for any participant in this process.

While some weight should be given to having a serious shipping  
implementation with nontrivialn market share, I hope I do not need to  
point out that weighing opinion strictly by market share is clearly  
anti-competitive.

> Non-HTML namespaces are for all practical purposes a non-starter as  
> they come with a string attached: a requirement for well-formedness,  
> not just of the extension, but of the entire page into which such  
> extensions can be placed.
>
> An HTML5 with a viable namespace mechanism and a consistent policy  
> of saying no to everything not in the charter is not only more  
> likely to complete on a reasonable schedule, it is more likely to  
> survive last call.

While I agree that a namespace mechanism in HTML may be useful, I do  
not think aggressively pushing features into foreign namespaces would  
be a good thing for authorability of the resulting language.

Regards,
Maciej

Received on Tuesday, 20 November 2007 23:27:05 UTC