Re: Separate Draft of Canvas API Uploaded to CVS

Hi, Maciej-

Maciej Stachowiak wrote (on 8/17/09 5:28 PM):
>
> On Aug 17, 2009, at 12:13 PM, Lachlan Hunt wrote:
>>
>> Also, I'd rather have the element's interface definition left within
>> HTML5 itself, and if any of this is to be split out, I'd prefer it to
>> be restricted to just the CanvasRenderingContext2D API and related
>> sections.
>>
>> Separating the interface definition means that APIs that interact with
>> the element itself are now defined in a separate specification, which
>> is something we've tried to avoid in HTML5 as it can create conflicts
>> if they're not maintained properly together. For example, if we ever
>> add a new attribute to <canvas>, we would need to update two specs
>> simultaneously, which really defeats the purpose of trying to maintain
>> this in an independent spec.
>>
>> It's also not clear to me what problem is being solved by generalising
>> the interface, nor why it needs solving preemptively for SVG.
>
> Agreed. It makes sense to split CanvasRenderingContext2D and related
> materials, but not HTMLCanvasElement. The HTMLCanvasElement interface is
> independent of any specific rendering context interface, for example a
> 3D context is being defined in a totally separate spec.

Here's what's currently defined in the Canvas 2D API spec as an 
interface for the element:

* width and width attributes: (note that these are the DOM attributes, 
not the markup attributes)... this is needed for the author to make code 
that understands the dimensions

* getContext() method: this gives access to the object with the drawing 
methods

* toDataURL() method: not strictly necessary, but a useful utility method

The way I see it, these should work in SVG in just the same way as they 
do in HTML.  Why define these in both HTML and SVG, when they can simply 
be defined in one place and reused?  The risk of maintenance and 
coordination problems that Lachy referred to is even more pronounced in 
this case.

I have the feeling I'm not understanding something here.  Where is the 
benefit of splitting definitions of critical Canvas API functionality 
into multiple specs (HTML5, SVG, and Canvas 2D API)?

With regards to the 3D context, that can simply build on the Canvas 2D 
API spec... I doubt anyone would implement the 3D context and not the 2D 
context.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Monday, 17 August 2009 21:50:00 UTC