Re: Separate Draft of Canvas API Uploaded to CVS

> 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:01 UTC