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

Adrian,

If we are going to place this in a separate specification then we will need
to include support for accessibility. How well we address that depends on
runway. For example, I believe we need a combination of:

- DOM/ARIA support
- equivalent alternative content
- Accessibility API support.

What is the timeline being projected for a separate canvas spec., relative
to HTML 5, if we were to separate it out?

Rich

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist


                                                                           
             Adrian Bateman                                                
             <adrianba@microso                                             
             ft.com>                                                    To 
             Sent by:                  Eliot Graff                         
             public-canvas-api         <eliotgra@microsoft.com>,           
             -request@w3.org           "public-html@w3.org"                
                                       <public-html@w3.org>,               
                                       "public-canvas-api@w3.org"          
             10/21/2009 03:05          <public-canvas-api@w3.org>          
             PM                                                         cc 
                                       Frank Olivier                       
                                       <franko@microsoft.com>, Doug        
                                       Schepers <schepers@w3.org>          
                                                                   Subject 
                                       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