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

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

I agree. For the eqivalent alternative content, a structure for 
fallback, something like <object> the <video> and <audio> elements 
could be very useful.
Thanks and Best Regards,




----- Original Message ----- 
From: "Richard Schwerdtfeger" <schwer@us.ibm.com>
To: "Adrian Bateman" <adrianba@microsoft.com>
Cc: "Eliot Graff" <eliotgra@microsoft.com>; "Frank Olivier" 
<franko@microsoft.com>; <public-canvas-api@w3.org>; 
<public-canvas-api-request@w3.org>; <public-html@w3.org>; "Doug 
Schepers" <schepers@w3.org>
Sent: Wednesday, October 21, 2009 2:57 PM
Subject: 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

Received on Wednesday, 21 October 2009 23:22:33 UTC