Re: ISSUE-201: Change proposal

On 2/10/2012 11:12 AM, Ian Hickson wrote:
> On Fri, 10 Feb 2012, Frank Olivier wrote:
>> I would like to submit http://www.w3.org/wiki/Canvas_hit_testing as a
>> change proposal for this issue.
>>
>> This proposal adds a method for authors to link bitmap regions (paths)
>> on a canvas element to canvas subdom elements, enabling simpler hit
>> testing and better coding patterns for canvas user interfaces. User
>> agents can use the region boundaries and element properties to provide
>> accessible user experiences.
> FWIW, it's my intent to add the feature described in this change proposal
> as part of the Path primitives feature which is the next on the list of
> things to add to canvas. I think it would be a mistake to address this in
> a piecemeal fashion rather than looking at all the current limitations of
> canvas at once and addressing them together to the extent that it makes
> sense.


In what manner is Frank's proposal incompatible with path primitives?

We've covered path primitives before, for some reason they were never 
added. Path primitives would allow authors to more efficiently express 
Paths to implementations,
because the paths could be stored in memory. The speedup is relatively 
small, but it would result in some speedup. It's small because rendering 
takes much more time.

var x = new CanvasPath().
x.rect(...); // etc.
ctx.addPath(x);

That seems completely compatible with Frank's proposal.

What do you mean by piecemeal? Are you asking for us to wait until you 
have your specifications together for version 2?
Canvas authors are not being held up, or otherwise actively requesting 
paths. That's because they are only a small boost.

We've been looking at Canvas a11y for years now, and can't continue to 
wait without reasonable cause. This is about meeting defined 
responsibilities.


> (Example of things that might be better than setElementPath() would be,
> for example, making stroke() and fill() for Path primitives take an
> optional Element; having touch UIs that describe onscreen controls while
> the finger is dragging around explicitly be told by the spec to call out
> widget boundaries by doing edge-detection on the paths painted so far;
> having hit detection be integrated with the same mechanism so that authors
> are more likely to use it; having clearRect() integrated with the same
> mechanism so that authors are more likely to not forget to clear the
> element assocations; etc.)

We already discussed that as a possible solution on the 
public-canvas-api list. We also discussed why it doesn't work, why it's 
a lot of work on vendors to implement, and why Canvas authors would have 
to use work-arounds if the method were implemented.

I'd ask you to consider the solutions we have presented, and respond 
with reasons why they are insufficient.

I'm happy to hear more examples from you. I'll certainly respond with 
information if we've already covered those examples.

The solutions we presented are simple, concise, can be implemented with 
small changes to existing code bases, they are based on accessible hit 
testing practices that have existed for decades. They have been under 
discussion for well over a year.

-Charles

Received on Friday, 10 February 2012 19:38:53 UTC