- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 27 Oct 2011 17:42:40 -0700
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- Cc: franko@microsoft.com, chucko@jumis.com, david.bolter@gmail.com, cyns@exchange.microsoft.com, public-html-a11y@w3.org, janina@rednote.net, jbrewer@w3.org, public-canvas-api@w3.org
Some feedback: Limiting to only allowing paths seems like a unfortunate limitation. For example it misses calls to drawImage which I think is quite common. I'd rather prefer a call where you say "all drawing operations from this point should be considered drawing for element X", then let the page do arbitrary drawing operations, then have a second call which says "i'm now drawing for element Y" or "I'm now drawing for no element". What is the use case for the zIndex argument? The actual pixel drawing operations hasn't had a need for that so far and instead rely on the painters algorithm. It seems better to me to have a direct mapping between the drawing operations and the accessibility API. Why return false rather than throw an exception if the element doesn't exist? Also what do you mean by "doesn't exist". If the element doesn't exist then how could the page have a reference to it and pass that reference to the function? Do you mean "element isn't inside the canvas"? In general I think I prefer the API I proposed in [1]. Can you describe what problems you were trying to solve with your changes compared to that proposal? [1] http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0195.html / Jonas On Thu, Oct 27, 2011 at 4:56 PM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote: > Hi Frank, > > Thank you for the call today. I am glad we are on the same page on the three > basic methods for hit testing. I took the basic methods that Jonas had put > out earlier on the list and the discussion we had in San Diego and put > together an active regions and hit testing section. I also agree with you > this is for when we have multiple interactive elements within canvas. I was > glad to see that customers are starting to come to Microsoft to talk about > building more interactive widgets with canvas - not because I want them to > but more because it shows we are making the right moves to address canvas > accessibility. > > Jonas, Charles, Frank, David, Cynthia > > This is a first draft and the section I would like you to look at is section > 16. We can change the names to whatever we want. I have not yet added spec. > information as to how existing functions like scrollElementIntoView should > work on these elements as they should be included in the layout engine > positioning per Jonas earlier feedback. I have also not stated how we would > convert the paths to rectangles for the underlying OS platform accessibility > APIs. We could either do this in the canvas spec. or in the accessibility > API mapping guide that Cynthia is leading. We just need to decide. > Personally, I prefer the one stop shopping. > > I am sure Ian will want to tweak or rewrite the algorithm section processing > as he has his own consistent way of doing that but I took my best shot at > it. > > Please review section 16. > > (See attached file: clickableregion.html) > > Since, like many of you I am going to TPAC, I will not have time to make > changes prior to the face to face. Janina please put a link to this document > in your canvas agenda for TPAC. > > See you all in California. > > > Rich Schwerdtfeger >
Received on Friday, 28 October 2011 00:43:49 UTC