Tab,
I think Sean Hayes' last post gave you more than enough clear use cases and
I have one for IBM that I cannot speak about. A while ago (in fact months
ago) I provided a Visio style application to Ian. We don't need any more
use cases. I would also point out that the major reason for this change is
so that low vision users can find and zoom to objects with their magnifier.
This can be done on all desktops but it cannot with canvas.
Ian always favors features tied to mainstream use. Hit testing is a hole in
canvas that has been left to authors to deal with and we should use it to
provide the information missing in the accessibility APIs.
Canvas must not ship as a w3c spec. unless it is accessible. So, you are
doing a lot to state what you don't like about the retained mode graphics
approach. What approach would you suggest would provide the necessary
accessibility information and provide a mainstream benefit?
Rich
Rich Schwerdtfeger
CTO Accessibility Software Group
From: "Tab Atkins Jr." <jackalmage@gmail.com>
To: Charles McCathieNevile <chaals@opera.com>
Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, Cameron McCormack
<cam@mcc.id.au>, Charles Pritchard <chuck@jumis.com>, Cynthia
Shelly <cyns@microsoft.com>, david.bolter@gmail.com, Frank
Olivier <Frank.Olivier@microsoft.com>, Mike@w3.org,
public-canvas-api@w3.org, public-html@w3.org,
public-html-a11y@w3.org
Date: 06/28/2011 02:01 PM
Subject: Re: hit testing and retained graphics
Sent by: public-html-request@w3.org
On Mon, Jun 27, 2011 at 4:20 AM, Charles McCathieNevile
<chaals@opera.com> wrote:
> On Thu, 23 Jun 2011 22:28:32 +0200, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>> On Thu, Jun 23, 2011 at 12:56 PM, Richard Schwerdtfeger
>> <schwer@us.ibm.com> wrote:
>>>> So normally, I imagine, hit testing would be done either by using
>>>> isPointInPath() or by custom code looking at a mouse event’s x/y
values.
>>>> I think this proposal doesn’t work with isPointInPath(), though, is
that
>>>> right?
>>>>
>>> I think it would but we would need to incorporate Z order and a notion
of
>>> the last drawn element to compute which element is on top. The user
agent
>>> would need to manage this.
>>
>> You are attempting to recreate a retained-mode API in an
>> immediate-mode API. Why is "use SVG" not sufficient for this?
>
> Because people don't - they use canvas instead. If that were not the
case,
> the whole effort to specify canvas would be solving a theoretical
problem.
That's not a useful answer. <canvas> is used for lots of things, of
which only a subset are better done in a retained-mode API, of which
only a subset are reasonably handled by mapping clicks into a DOM
node.
I elaborated my objection to this approach in a later email. This
development thrust seems to be happening without any clear use-cases
to address, and with a preference for minimally-invasive edits to the
2d canvas context. These seem very likely to give a bad result that
doesn't solve anything well.
I don't think we'll come up with a *good* result until we have clear
use-cases that we can then solve.
~TJ
