Re: hit testing and retained graphics

On 6/23/2011 2:48 PM, Tab Atkins Jr. wrote:
> 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:
>>> 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.
> 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.
The 2d canvas API is similar to every other 2d API.

It's a low level API, just as libcairo is a low-level API in Mozilla 
products, skia a low level
API in Google products, and so on. I don't see how "crappy" comes into 
it. You
seem to be comparing two un-like items.

Canvas is not intentionally inaccessible.

What kind of "easier and better" are you looking for? Many people have built
libraries up around Canvas, I don't think they're looking for a 
wholesale replacement
simply because a handful of methods are absent.

I've looked at several code bases, and implemented canvas myself. These 
proposals
are both -easy- on the implementer and -easy- on the developer; they're 
also -easy-
on the accessibility vendor.

>> 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.
I'd appreciate your attention to the proposal at hand, as I know you 
have experience in this area;
we do not want to insert something that is defective, in our attempt to 
support accessibility in HTML5.

Is there something defective in the proposal that's being discussed?
You've not addressed that proposal other than to rebut the use case. 
That's not moving us forward.

>
>> 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.
Tab, I've answered it many times. Richard has put it forward.

Explaining use cases is exhausting, as you and Ian consistently rebut them.
If there is a schema you would like to put forward, within which I can 
fill-out
answers that would adequately state my case, please do so.

It appears to be a foregone conclusion with you and Ian that Canvas can 
not be used to
create composite widgets with ARIA, in practice with WCAG 2.0.

I believe you are both incorrect in that assumption.
> 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.
You and I have different ideas as to what "free accessibility" means.

That said... this schema you're imagining could and likely has been worked
out in scripting environments. Keep in mind that people often use 
scripting libraries,
rather than directly using the DOM.. It's common.. very common.

We can't -prototype- the items in your imagination, in the scripting 
environment,
without the appropriate vocabulary. Perhaps in your imagination, prototypes
should be written in C++; but for the rest of us, it's more effective 
and efficient
to write in ECMAScript which runs across browsers than to take a single 
browser
toy with it; and wait a decade for XBL2 to be released.

> 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.
Please detail what you mean by "actual analysis". Please provide supporting
facts to your claim that there are "a *lot* of ... problems [without] 
useful solutions].

Please do that, so that we can move this discussion forward. I'm happy 
to do the work here.
I've software installed, many operating systems, many browsers, my eyes 
on many source code trees,
and tens of thousands of lines of canvas-based UI components.

> 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.
Had I expected such a thorough response as the one you've provided 
here... I would
have toned down my reply to you... sorry about that.

-Charles

Received on Thursday, 23 June 2011 22:03:13 UTC