W3C home > Mailing lists > Public > public-canvas-api@w3.org > January to March 2010

Re: adom proposal

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Fri, 19 Feb 2010 15:32:43 -0600
To: David Bolter <david.bolter@gmail.com>, Michael Cooper <coopermr@us.ibm.com>, janina@rednote.net
Cc: Charles McCathieNevile <chaals@opera.com>, cyns@exchange.microsoft.com, Steven Faulkner <faulkner.steve@gmail.com>, Frank Olivier <franko@microsoft.com>, jcraig@apple.com, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, surkov.alexander@gmail.com
Message-ID: <OFE599D8B5.85D3D8C1-ON862576CF.007310C5-862576CF.00765A49@us.ibm.com>

Thanks David,

These were the only comments I received since I made my request so I will
try to incorporate them into the spec. ready code. We will vote (within the
group on Monday).

Michael,

Janina asked for a straw poll. I would like to have the group deal with an
remaining word-smithing on Monday at our 2pm call after which I will post
the changes for the task force straw poll. I would like to have the results
of the straw poll by mid-Wednesday so that I may include the changes in the
defect tracking system for Ian - assuming it is a go. We are not talking
about a large change. We have a February 25, 2010 due date which I would
like to adhere to.

There is still an outstanding action item for Steve Faulkner for caret
tracking in the <canvas> script API effort but that effort has been put on
a different release track from HTML 5.

Rich

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist


                                                                           
             David Bolter                                                  
             <david.bolter@gma                                             
             il.com>                                                    To 
                                       Richard                             
             02/19/2010 09:17          Schwerdtfeger/Austin/IBM@IBMUS      
             AM                                                         cc 
                                       "public-canvas-api@w3.org"          
                                       <public-canvas-api@w3.org>,         
                                       jcraig@apple.com,                   
                                       cyns@exchange.microsoft.com,        
                                       surkov.alexander@gmail.com, Frank   
                                       Olivier <franko@microsoft.com>,     
                                       Charles McCathieNevile              
                                       <chaals@opera.com>, Steven Faulkner 
                                       <faulkner.steve@gmail.com>          
                                                                   Subject 
                                       Re: adom proposal                   
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Hi Rich,

Thanks for driving this.

I can't speak for Mozilla as a whole, but thinking of all our discussions
and the feedback that has come from people inside and outside this group,
this approach seems like a reasonable compromise to me, and I'd like to
hear what others think.

Nits:

For the introductory paragraphs:

" When possible a facility must me" should be "be"

" accessible binding" needs to be defined. "Binding" might get confused
with XBL etc.

" The determination of the disposition of the <canvas> subtree can be
determined at load time." could be "can be done at load time."

" When set to true it indicates that the canvas subtree is to be use as a
direct accessible subtree of canvas" could be " When set to true it
indicates that the canvas subtree is to be used as a directly keyboard
operable accessible subtree of canvas".

" The fallback content can come over the wire" could be "Progressive
enhancement can be achieved since the fallback content...", and " a script
can determine whether canvas is renderable" could be "a script can use
feature detection to determine...".


In the proposed text for html5:

I would say something about the adom indicating that the sub-tree of canvas
is intended to interact (be kept in sync?) with the canvas rendering. I
would not prescribe that the " rendering of the subtree is controlled by
script through the canvas API".

Regarding the last sentence " Add the following definition to the HTML 5
glossary:" was there more here?

cheers,
David
On 18/02/10 2:20 PM, Richard Schwerdtfeger wrote:


      Folks,

      I would like to take my adom proposal change to canvas to vote. Do
      you
      support it? I have a due date of February 25. I need to get the last
      draft
      in spec. ready format for the weekend and after the last meeting we
      appear
      to have consensus barring some word smithing. We still have  a
      dependency
      on Steve to address action item 19 regarding the caret.

      http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0163.html


      Janina wants to do a straw poll early next week as there is a Feb. 25
      due
      date for this. It would seem that the Opera example would be an
      excellent
      best practice for some content. We would simply set adom to true when
      canvas is supported. The author needs to ensure visual focus is drawn
      on
      the canvas.

      Rich

      Rich Schwerdtfeger
      Distinguished Engineer, SWG Accessibility Architect/Strategist






graycol.gif
(image/gif attachment: graycol.gif)

pic13621.gif
(image/gif attachment: pic13621.gif)

ecblank.gif
(image/gif attachment: ecblank.gif)

Received on Friday, 19 February 2010 21:33:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:49 UTC