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 20:46:36 UTC