Re: Separate Draft of Canvas API Uploaded to CVS

Hi, Lachlan-

Lachlan Hunt wrote (on 8/17/09 3:13 PM):
>
> 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.

Thanks for the tip.  There are experimental implementations of SVG that 
already include the Canvas 2D API on the <image> element, and it seemed 
to work fine... what specific problems are you identifying?  Personally, 
if we can avoid adding a new element to SVG expressly for this purpose, 
I think that would be better.  I suppose there may be some value in 
adding the <canvas> element to SVG, if only for parity with HTML for the 
platform, but I don't see a really compelling case against adding new 
functionality to <svg:image> otherwise (or in addition).

Unlike <img>, <image> already has a container model that would allow for 
metadata and fallback content (and SVG has a more sophisticated fallback 
model anyway, using <switch>).  Like <img> and <canvas>, <image> has 
appropriate @width and @height attributes.

But if there are problems with this approach we haven't seen, we'd be 
grateful to hear about them in advance, so we can avoid them.


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

I may not have been clear enough in the spec, but the interface 
definition in the Canvas API spec draft is intended as an abstract 
interface, such that the <canvas> element interface can be specified in 
HTML.  But that functionality is also related closely enough to the 
drawing API that I think it's useful as a generic addition.


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

What specific attributes are you talking about adding to <canvas> that 
couldn't be added to the Canvas 2D API spec (or a successor) instead? 
I'd prefer to deal in real-world use cases here.

In any case, this is intended as an HTML WG deliverable... I'd hope that 
the HTML WG could coordinate with itself well enough. :)


> It's also not clear to me what problem is being solved by generalising
> the interface, nor why it needs solving preemptively for SVG.

I'm not sure what you mean by this.  The SVG WG has long recognized the 
need for some pixel-based operations (such discussions precede Canvas, 
even) which are more appropriate for something like the Canvas API 
versus the vector-based SVG operations.  Reusing the Canvas API this way 
is the obvious choice.  Can you explain what you mean by "preemptively"?

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

Received on Monday, 17 August 2009 19:49:16 UTC