Re: hit regions

On 8/19/2012 9:55 PM, Rik Cabanier wrote:
>> A key design goal, as I understand it, was to avoid turning canvas into
>> a retained mode API. The author is responsible for managing any object graph;
>> canvas is just a display.
> Isn't the new "current default path" a step towards retained graphics?

We went through this discussion at length on public-canvas-api.

At the point that authors take responsibility for managing the DOM, 
they've departed from the strict sense of a bitmap API and are now in 
the world of ARIA.
ARIA+DOM is a retained mode API.

These API additions to Canvas are intended to push Canvas support into 
ARIA+DOM.
By having canvasContext.addEventTarget(element), we're adding spatial 
information to the DOM itself.

We are now saying that hey, this element over here, it has a path, on 
the screen, and a user can interact with that path.
Our [strong] motivation was to fix Canvas 2D to meet accessibility 
requirements.

Once we fixed keyboard events, we went on to pointer events.

Here is one of the more recent proposals (By Frank from Microsoft):
http://www.w3.org/wiki/Canvas_hit_testing

It followed our original proposal for "setPathForElement" with a zIndex 
attribute (Richard from IBM):
http://lists.w3.org/Archives/Public/public-canvas-api/2011OctDec/att-0019/clickableregion.html

Here is a lengthy history of a11y discussions on public-canvas-api:
http://www.paciellogroup.com/blog/2011/12/html5-canvas-accessibility-discussions-2009-2011/

This effort is a continuation of the work completed on drawFocusRing, 
which supports keyboard accessibility and visual alignment for Canvas 2d:
http://dev.w3.org/html5/canvas-extensions/Overview.html

These issues were brought up because of deficiencies in the Canvas API. 
We identified specific ATs which could not work with Canvas 2d correctly,
and we addressed the flaws in the Canvas 2d API to support them. These 
include AISquared's ZoomText and Apple's VoiceOver for Mobile Safari.

Note, Canvas 2D paths are not intended to have multiple parents when 
paths overlap. That's a part of the CSS box model, unnecessary in our 
use cases.

>>> Another issue would be with removing hit regions that previously
>>> overlapped others. How would you restore the previous pixels?
>> The WHATWG spec for "removeRegion" says: ...
> Yes, I hadn't noticed this before.
> The fact that you can remove a region and then have to 'garbage-collect' the other regions also implies retained graphics.
> With region removal, I can see how the hitregions fit into an immediate mode API. Maybe that was a late addition?

The WHATWG spec was created independently of all other participants.
http://lists.w3.org/Archives/Public/public-canvas-api/2012JanMar/0047.html

I do not support the WHATWG spec change.

We can accomplish a similar feature set with more precise changes to the 
spec.
Indeed, we are accomplishing that feature set.

The primary purpose of the WHATWG change was not accessibility.
Further, the Baseline metrics and re-usable paths can be accomplished by 
very minor additions to the Canvas API, already proposed and partially 
implemented within the public-canvas-api WG.

-Charles

Received on Tuesday, 21 August 2012 14:53:09 UTC