Re: Separate Draft of Canvas API Uploaded to CVS

On Mon, Aug 17, 2009 at 4:28 PM, Maciej Stachowiak<mjs@apple.com> wrote:
>
> On Aug 17, 2009, at 12:13 PM, Lachlan Hunt wrote:
>
>> Doug Schepers wrote:
>>>
>>> I took the initiative to create a draft [1] of the
>>> Canvas 2D API that is split out from HTML5, and just concentrates on the
>>> API, rather than the <canvas> element. The <canvas> element itself would
>>> need to remain in the HTML5 spec, and would simply reference this spec
>>> for the drawing interface.
>>>
>>> I took the opportunity to make it a little more generic (i.e., not
>>> HTML-specific), so that SVG could also include the Canvas API (for
>>> example, to be used on <image> elements in SVG);
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> It's also not clear to me what problem is being solved by generalising the
>> interface, nor why it needs solving preemptively for SVG.
>
> Agreed. It makes sense to split CanvasRenderingContext2D and related
> materials, but not HTMLCanvasElement. The HTMLCanvasElement interface is
> independent of any specific rendering context interface, for example a 3D
> context is being defined in a totally separate spec.
>
> Regards,
> Maciej
>
>
>

I don't see that there's a conflict.

Doug defined an interface in the document, that forms the contract
between the 2D API and the applications that support this API. HTML 5
has a physical implementation of the HTMLCanvasElement, implementing
the required properties and methods as defined in the handshake. If
there's new attributes needed on the HTMLCanvasElement, add them.
Unless they need to be reflected within the API, it shouldn't matter
what HTML 5 does.

Same with an SVG implementation, and so on.

As for a 3D implementation, again, though, there's nothing in the 2D
API interface that would prevent someone implementing a different API
for with the same interface but different methods, or even a different
functionality, as long as the interface contract remains the same. I'd
be concerned about redefining the basic functionality, but all the
interface is, is a handshake.

Shelley

Received on Monday, 17 August 2009 23:05:11 UTC