W3C home > Mailing lists > Public > public-canvas-api@w3.org > October to December 2011

Re: draft of hit testing on active regions (actually paths) in canvas

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 27 Oct 2011 17:42:40 -0700
Message-ID: <CA+c2ei88wPn1sJ-MPy0u0c7Pawag=5g1JFwQ8PoyzT0LtYG67g@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 28 October 2011 00:43:49 GMT