- From: Joe D Williams <joedwil@earthlink.net>
- Date: Mon, 17 Aug 2009 14:25:18 -0700
- To: "Lachlan Hunt" <lachlan.hunt@lachy.id.au>, "Doug Schepers" <schepers@w3.org>
- Cc: "HTMLWG WG" <public-html@w3.org>, <public-canvas-api@w3.org>
> In other words, clearly explain why you need to have the element > interface defined within that spec, rather than just restricting the > spec to the 2D context API. Maybe ask [emphasis] ,,, "In other words, clearly explain why you need to have the [pixel-based] element interface defined within that [existing SVG] spec, rather than just restricting the [existing SVG] spec to the [vector-based] 2D context API. " Could use better phrasing, but uniting these into the same namespace would give a nice combination of features for 2D interactive aspects. Important to be able to compose layers of the different forms. That doesn't eleiminate the need for <canvas> as a native element unrelated to SVG. Thanks and Best Regards, Joe ----- Original Message ----- From: "Lachlan Hunt" <lachlan.hunt@lachy.id.au> To: "Doug Schepers" <schepers@w3.org> Cc: "HTMLWG WG" <public-html@w3.org>; <public-canvas-api@w3.org> Sent: Monday, August 17, 2009 1:45 PM Subject: Re: Separate Draft of Canvas API Uploaded to CVS > Doug Schepers wrote: >> 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? > > I was only advising caution. I can't think of any specific > problems, but I'm not that familiar with SVG. That's why I said I'd > leave it up to the people working on SVG. > >>> 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. > > We don't have any plans to add any now, but needs change over time > and new features, including attributes, get added frequently. My > point is that we shouldn't make things more difficult than they need > to be, and I'm not convinced there is a need to have the element's > API defined in a separate spec at all. > >>> 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"? > > I'm not questioning SVG's need for pixel-based operations. I mean, > what problem is being solved by defining a generic interface, rather > than simply letting HTML and SVG define their own interfaces > independently. It just seems like an unnecessary level of > abstraction. > > In other words, clearly explain why you need to have the element > interface defined within that spec, rather than just restricting the > spec to the 2D context API. > > -- > Lachlan Hunt - Opera Software > http://lachy.id.au/ > http://www.opera.com/ >
Received on Monday, 17 August 2009 21:26:02 UTC