Re: Separate Draft of Canvas API Uploaded to CVS

On Aug 17, 2009, at 12:13 PM, Lachlan Hunt wrote:

> Doug Schepers wrote:
>> I took the initiative to create a draft [1] of the
>> Canvas 2D API that is split out from HTML5, and just concentrates  
>> on the
>> API, rather than the <canvas> element. The <canvas> element itself  
>> would
>> need to remain in the HTML5 spec, and would simply reference this  
>> spec
>> for the drawing interface.
>>
>> I took the opportunity to make it a little more generic (i.e., not
>> HTML-specific), so that SVG could also include the Canvas API (for
>> example, to be used on <image> elements in SVG);
>
> I'd be cautious about trying to overload the <image> element in SVG  
> with the canvas API.  We learned with HTML that trying to overload  
> elements with too much different functionality can create  
> implementation problems.  But I'll leave that to the people working  
> on SVG to sort out if they want to do that.
>
> 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.

Regards,
Maciej

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