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

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.

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.

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

>
>
> But that's only what I think would be reasonable to do.
>
> - Sam Ruby
>

Received on Tuesday, 20 November 2007 01:00:04 UTC