Re: Canvas 2D API specification update

On Thu, Oct 22, 2009 at 3:25 AM, Ian Hickson <ian@hixie.ch> wrote:
> On Wed, 21 Oct 2009, Eliot Graff wrote:
>>
>> At Microsoft, we agree with the sentiments expressed by Doug, Maciej,
>> and others about creating a separate Canvas 2D API specification. We are
>> prepared to offer editorial resources to aid in the completion of this
>> separate specification.
>
> I'm a little concerned about this process introducing a significant number
> of editorial problems in the spec.
>
>> Our updated version is published at
>> http://dev.w3.org/html5/canvas-api/canvas-2d-api.html
>
> For example, from a _very_ brief look at the document (i.e. things I
> noticed in the first 60 seconds of looking at the draft):
>
> * Element interface name is wrong (should be HTMLCanvasElement)

That would be an inappropriate interface name if Canvas is seen as
being independent from HTML. For instance, discussion has occurred
about the use of Canvas with SVG.

>
> * Unclear definition of conformance classes -- is a host language a
> conformance class?
>
> * We really should keep all the element-specific stuff in the HTML spec
> and the 2D API in its own spec, if we split it out at all.
>

That sounds reasonable. Do you have specifics?

> * None of the recent fixes have made it through, e.g. the recent fix to
> define how shapes are drawn with respect to the globalCompositeOperation
> is not included.
>

One assumes that any recent changes made to Canvas in HTML5 would be
evaluated for possible inclusion in a separate document. That's one of
the concerns about parallel updates, while we discuss the need for
separating out pieces of the current HTML5 spec.

> * References to WebIDL have been lost.
>
> * The composite operators have been reordered into an order that doesn't
> make much sense (alphabetical, it seems).
>
>
> IF we're going to split out the 2D API -- and I'm not really sure if at
> this point that's something we should do, frankly -- then I would much
> rather we do it based on the text in the HTML5 spec now, and would much
> rather we have an editor who is able to give this the full-time attention
> that it needs.
>

I don't believe either Eliot or Doug would volunteer to work on this
new specification if they weren't willing to make a commitment in time
to ensure the work was done properly. And I imagine there will be
other editors to come on board to both share the work and ensure a
greater coverage of the interested community.

You have made changes in Canvas only recently. In fact, the last few
days if I remember correctly. I would assume that the Canvas 2D
interested folks would want to review your changes to see if they want
to implement or not. Not blindly echoing what you do does not indicate
either lack of interest or commitment.

> However, I'm really not sure at this point that it even makes sense to
> extract the API anymore. The API intergrates pretty tightly with the rest
> of HTML, for example it refers to HTMLVideoElements, the HTML5 "structured
> clone" feature is defined in terms of canvas interfaces, and so on. There
> would have to be a two-way reference, which would be a maintenance
> nightmare, and which would just delay the progress of both documents.
>

Your statement about integration with HTML is specifically why we need
to consider separating Canvas out now, before its too late.

Right now, Canvas has a real possibility of existence outside of HTML,
for uses in something like SVG. If we tightly integrate Canvas, which
is basically a 2D API, into HTML, which is a web page markup, we again
add to the overall size of HTML5 (unnecessarily), as well as tying
Canvas into a document, which will probably its growth and reach.
Unnecessarily, too, because there really isn't "markup" specific about
Canvas, other than the Canvas element itself, which should stay in the
HTML5 document.

The concept of structured clone is, itself, inappropriate in HTML5. It
is a good concept when it comes to web applications, but not when it
comes to discussions about HTML, as a markup language. No, not even
the HTML specification also includes a description of the DOM.


> What are the problems that we are trying to solve by splitting out the API
> at this point?
>

These have been discussed, in the past, and in the links that Eliot
provided in his email.

> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>
>

Shelley

Received on Thursday, 22 October 2009 14:16:34 UTC