- From: Doug Schepers <schepers@w3.org>
- Date: Mon, 17 Aug 2009 15:49:03 -0400
- CC: HTMLWG WG <public-html@w3.org>, public-canvas-api@w3.org
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