Re: hit testing and retained graphics

On Thu, Jun 23, 2011 at 1:56 PM, Charles Pritchard <chuck@jumis.com> wrote:
> On 6/23/2011 1:28 PM, Tab Atkins Jr. 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?
>
> Tab, we've been through this one before.
>
> "use SVG" is not a relevant statement -- we're trying to make Canvas
> accessible.

By turning it into a retained-mode API bit-by-bit.  This is almost
certainly a bad approach.  Either use an API designed for
retained-mode graphics, like SVG, or create a drawing mode for
<canvas> that's retained-mode from the ground up.

The 2d canvas API is crappy.  That's intentional, so it's as simple as
possible and quick to implement.  If you want something not-crappy
that's also fairly different, there's a pretty good chance that it
would be easier and better to start from scratch with a new context.


> Assistive technology products create their own retained-modes; we are
> focused on
> exposing sufficient information for those products to operate -- at the same
> time, we're trying
> to make things a little easier on developers, using those same methods. This
> is the "stalking horse" technique
> that Ian Hickson often puts forward as a reason for updating specifications.

On the other hand, "minimally disruptive" additions are usually worse
than simply creating it correctly from the start.


> Retained-mode semantics are not exclusionary to immediate-mode APIs; OpenGL
> is a good example,
> as mentioned by Wikipedia.  We're restricting the "retained mode" to items
> which are in the DOM,
> The shadow DOM is acting as the retained mode API, just as it should.
> Canvas is still in an immediate mode.
>
> ( wikipedia link: http://en.wikipedia.org/wiki/Retained_mode )
>
> I'd appreciate it, Tab, if you'd add something to the conversation, instead
> of condescending
> developers like me by repeating the same comment over and over.

I've followed these discussions, at least the ones that appeared on
the html mailing lists (if any occurred elsewhere I haven't read
them).  I haven't yet seen anyone seriously answer the question of
"why not use SVG?" or "why not create a new canvas context that's
better suited for this kind of thing?".  It appears to be a foregone
conclusion that we must use the existing 2d context and patch it into
working.  The reasoning behind this is not obvious to me.

As a simple example, I can imagine a 'dom' context, where you can
directly attach drawing sequences to dom elements, and they're
automatically drawn onto the canvas each frame.  The positioning,
z-order, and other aspects (the 'hidden' attribute, frex) can be
automatically taken into account when drawing.  You can also invoke
some magic so that when you draw, say, a textarea you can
automatically get an interactive section that works just like a native
textarea.  Something like this would have obvious benefits for authors
doing anything close to the DOM, and would solve a lot of
accessibility issues much more cleanly - you'd have an automatic and
well-defined relationship between drawn objects and the associated DOM
elements, you'd get free accessibility for text and similar things,
etc.

Basically, I haven't seen any actual analysis of the problems that are
attempted to be solved here.  There are a *lot* of accessibility
problems with the 2d canvas context, and it's unclear to me that we'll
get any useful solutions without a more methodical approach to the
problems.

I apologize for the condescending tone of my previous message,
however.  It was meant to invoke what I explained in this email, but
its terseness did not communicate that well.

~TJ

Received on Thursday, 23 June 2011 21:49:15 UTC