Re: Separate Draft of Canvas API Uploaded to CVS

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.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Monday, 17 August 2009 19:13:51 UTC