Re: hit testing and retained graphics

On Wed, Jul 6, 2011 at 2:48 PM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:
> From: "Tab Atkins Jr." <jackalmage@gmail.com>
>> In this specific topic, the right way to get bounds information for
>> objects, associate drawn images with captions, keep text around so it
>> can be read later by a machine, etc. is to use a retained-mode API.
>> The wrong way is to use an immediate-mode one.
>>
>> We can choose to patch the latter into the former. It has a good
>> chance of turning out badly, because the basic assumptions underlying
>> the two approaches are somewhat incompatible. Or, we can promote
>> existing examples of the former (like SVG), find out what problems
>> they have that make them difficult to use, and fix them. Or, we can
>> come up with new retained-mode solutions that are designed up-front to
>> solve the problems we know of and be easy to use.
>>
>> I'm on the side of one of the latter solutions, but only because I
>> think it has a better chance of solving accessibility problems
>> "automatically". I am *strongly opposed* to any solution that is
>> completely optional, as that will leave the large majority of
>> applications using the relevant technology less accessible.
>
> Tab, I would support a new retained-mode solution that would allow for
> getting accessibility automatically. Were you thinking of tossing the
> existing 2D canvas api for a new one or writing a modification to it that
> operated off a retain mode model?

I don't know, all we've done so far is talk about use-cases.  If I
were to propose anything with canvas, though, it would probably be a
new context.


> Do you think this would garner support from the other browser vendors?

Depends on what it is, and how good it is.  Honestly, I suspect it
would be a bit of an uphill battle to get browsers to make a new
retained-mode API instead of just fixing whatever problems SVG has.
The hard part of implementing is the graphics side, not the API side,
but it's the API side that needs love if you want authors to use it.


> A way to force retained mode and hit testing would be to basically say that
> in order to state that canvas is an element such that unless an author
> creates a context, binds it to a separate fallback DOM object, applies a
> bounding path, and applies a Z order that pointing events would not be
> processed by the user agent on the canvas element. That would certainly
> force the issue. I suspect you could keep most of the API you have.

That won't work.  It makes it impossible to do reasonable things with
canvas that need mouse interaction but *can't* reasonably map to an
accessible subtree.  For example, my little Colliding Circles demo
<http://xanthir.com/demos/collidingcircles> is a perfectly reasonable
thing to do in canvas, but it's nonsensical (or at least useless) to
represent it in an alternate form with a subtree.

It's also a very "stick" approach, which is less preferable to a good
"carrot" approach.

~TJ

Received on Wednesday, 6 July 2011 23:33:58 UTC