RE: Canvas 2D API specification update - defining the element or not

[I've included Eliot's mail about his Canvas API specification update below in case it takes a while to show up.]


When Doug created his draft for a separate Canvas spec, he pulled out an abstract definition of the canvas element so that it could be reused in other contexts such as SVG. Eliot didn't make any changes like this in editing his version of the document instead leaving it as Doug defined.

Nevertheless, there was quite a bit of feedback about this and I've included some quotes below. It seems like there are a few choices:

1) Keep spec as it is with CanvasElement : Element.

2) Continue to define the CanvasElement interface in the spec but with no implied inheritance specified (possibly per Erik's feedback) and let consuming specs tie this into concrete element definitions (this has the advantage that APIs such as getContext() are only defined once here).

3) Remove CanvasElement from the standalone spec, let the consuming specs define what elements they want to use to represent a canvas, and make this spec purely about the 2D Canvas API context. (Lachlan, Maciej, and others).

I think that the third option is preferable provided that it doesn't cause a problem with incorporating the improved accessibility support that we believe needs to be added. I'd also be happy with option two. I agree that the current expression showing a link to Element and not HTMLElement is problematic.

Cheers,

Adrian.

References:

Doug wrote (http://lists.w3.org/Archives/Public/public-canvas-api/2009JulSep/0004.html):
> I may not have been clear enough in the spec, but the interface 
> definition in the Canvas API spec draft is intended as an abstract 
> interface, such that the <canvas> element interface can be specified 
> in HTML.  But that functionality is also related closely enough to the 
> drawing API that I think it's useful as a generic addition.

Erik wrote (http://lists.w3.org/Archives/Public/public-canvas-api/2009JulSep/0058.html)
> Why does the interface need to inherit from Element? Isn't it more 
> straightforward that the element that wants to use the canvas 
> functionality inherits the CanvasElement interface instead? I'd prefer 
> it if the CanvasElement interface was completely standalone.

Lachlan wrote (http://lists.w3.org/Archives/Public/public-canvas-api/2009JulSep/0003.html):
> It's also not clear to me what problem is being solved by generalising 
> the interface, nor why it needs solving preemptively for SVG.

Maciej wrote (http://lists.w3.org/Archives/Public/public-canvas-api/2009JulSep/0007.html):
> 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.



On Wednesday, October 21, 2009 12:58 PM, Eliot Graff wrote:
> In his mail describing why he created a separate Canvas 2D API
> specification, Doug Schepers wrote [1]:
> 
> > There is a chance that currently Canvas could be a blocker on progress
> > for the HTML5 spec, and at this point, Canvas is so widely implemented
> > that I don't think it's at risk, so I hope this isn't disruptive.  I
> > am available to help with any editing that needs doing, but I hope
> > that others will also work with this draft, and step into the editor
> role.
> 
> At Microsoft, we agree with the sentiments expressed by Doug, Maciej [2],
> and others about creating a separate Canvas 2D API specification. [3]  We
> are prepared to offer editorial resources to aid in the completion of
> this separate specification. We have looked over Doug's initial document,
> made some editorial enhancements, and are prepared to follow through in
> taking feedback and maintaining the specification.
> 
> We believe that some sort of accessibility API functionality is needed in
> the canvas element. However, the exact nature and depth of that
> functionality presents a dilemma that may block progress on the HTML5
> spec. We also think that the Canvas 2D API may be a desirable feature
> used in other technologies such as SVG.
> 
> Starting with Doug Schepers' initial draft, we made changes to get the
> document to adhere to the W3C PubRules [4], enhance readability, and
> improve logical flow of the document. In addition, we foresee adding
> sample code throughout the specification, where appropriate. No normative
> changes have been made. As with all drafts, the Canvas 2D API
> specification is still a work in progress. We would like to solicit
> feedback about the changes that were made (see below TODO) and about
> further changes that the working group would like to see.
> 
> Our updated version is published at http://dev.w3.org/html5/canvas-
> api/canvas-2d-api.html.
> 
> [1] http://lists.w3.org/Archives/Public/public-canvas-
> api/2009JulSep/0002.html
> [2] http://lists.w3.org/Archives/Public/public-canvas-
> api/2009JulSep/0007.html
> [3] http://lists.w3.org/Archives/Public/public-html/2009Aug/0628.html
> [3] http://www.w3.org/2005/07/pubrules
> 
> Edits:
> PubRules verified or applied throughout the specification, including
> fixing broken links and applying accessibility requirements.
> Addition of normative references to remove reliance upon links to HTML5
> specification General language, formatting, and logical edits, such as:
> 	Alphabetizing attributes and methods within existing sections
> 	Editing sentences to make them easier to understand
> 	Breaking long sentences, noun stacks, etc. to enhance readability
> 	Reordering paragraphs to create more seamless flow within sections

Received on Wednesday, 21 October 2009 20:21:07 UTC