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

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.

> For example, take a look at the SVG Working Group Charter: 
> <http://www.w3.org/2004/10/svg-charter.html>. Notice that the following 
> prominent features of SVG 1.2 Tiny are not explicitly listed:
> 
> - Multimedia embedding (<video>/<audio>)
> - A subset profile of the core DOM
> - A novel API for accessing DOM attributes and CSS properties that 
> introduces a new "traits" concept
> - Socket-level networking API
> - URI-based networking API
> - Support for Java as a scripting language
> 
> Many of these were deferred to a requirements document written after the 
> fact, or perhaps just considered subsumed under "utility DOM APIs". 
> Nontheless SVG Tiny 1.2 has made it to Last Call. This may be a hint 
> that debating or fine-tuning the charter is not a productive use of time.

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.

>> One thing that I think would be reasonable, would be for the charter 
>> to define a clear mechanism by which new markup and new DOM APIs can 
>> be added without modifying the "core" definition of HTML5.  Such a 
>> effort could be grounded by real use cases: SVG, MathML, canvas, 
>> offline-sql.
> 
> Are you talking about a technical mechanism or a political mechanism? A 
> separate specification could define a new HTML element right now if it 
> wanted to, but that would be considered unacceptable practice, and would 
> be confusing. Separate specifications already can and do define elements 
> in non-HTML namespaces and global APIs unrelated to HTML,

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.

- Sam Ruby

Received on Tuesday, 20 November 2007 14:12:00 UTC