Re: hit testing and retained graphics

Hi, Charles-

<meta>Can you please mark your comments more clearly, with empty lines 
between your comments and the passages you're quoting?  You emails are 
hard for me to read.</meta>

Charles Pritchard wrote (on 7/7/11 1:54 PM):
> On 7/7/2011 10:46 AM, Tab Atkins Jr. wrote:
>> On Thu, Jul 7, 2011 at 10:38 AM, Charles Pritchard<chuck@jumis.com>
>> wrote:
>>> On 7/7/2011 10:07 AM, Doug Schepers wrote:
>>>> 2) Make the shape, size, and position information available through a
>>>> special accessibility API, updated and maintained in parallel to
>>>> changes to
>>>> the rendered shape;
>>> This API already exists (with shape as an exception); it's the
>>> accessibility
>>> tree and its implemented by most vendors as a separate
>>> tree which is updated when changes are made to the DOM tree.
>>
>> This is incorrect. Size and position are *not* drawn from the
>> accessibility subtree. All three pieces of information that Doug
>> listed have to be explicitly indicated by the author in your proposal.
>
> He said that we'd make the information "available". Yes, of course the
> author has to indicate the information in the first place.


>> (I could see a solution where this isn't the case, and the DOM
>> actually *does* act as a form of scene graph, but that probably
>> requires a new context to be written. It's also remarkably similar to
>> Doug's proposal to put Canvas in SVG.)

A better characterization of my proposal is to have a shared API that 
makes it equally easy for an author to create an SVG element or a Canvas 
shape, and an extension to the Canvas subtree stuff that points to any 
SVG elements thus created.  But yes, I'd like to be able to use Canvas 
in SVG, where appropriate.


> In SVG, the author also sets up the size and position information.

Not necessarily.  In dynamic images, the SVG objects might be changed 
without the author doing anything other than "setting the stage":
* a script might animate or otherwise change an element
* a CSS style rule might be applied to an element, including a transform
* a declarative animation (SMIL or CSS) might move, shift colors, grow 
or shrink, or otherwise change an element
* a user might drag an element, or otherwise move it

Any of these things are automatically "tracked" in SVG, and a UA should 
be able to expose them.


> It's with semantic HTML that the UA may "automatically" handle position
> and sizes.

I don't see why you're drawing this distinction.


> SVG and Canvas both require the author to decide that something is being
> paintedand what those shapes are.

SVG saves the state automatically as part of its logical and rendering 
models.  Canvas "forgets" the state.  You are proposing to add 
functionality to have Canvas save the state, either automatically or by 
author action.

There are two open questions this raises:
1) Should we expose this "state information" somehow?
2) How should we do it?

I think the answer to (1) is "yes", for at least some limited set of 
cases [1].

I think the answer to (2) does not yet have consensus, but lets not keep 
pretending that the answer to (1) is the answer to (2), or that browser 
vendors are necessarily objecting to (1).

[1] http://www.w3.org/WAI/PF/HTML/wiki/Canvas_Accessibility_Use_Cases

Regards-
-Doug Schepers
W3C Staff Contact, SVG, WebApps, Web Events, and Audio WGs

Received on Thursday, 7 July 2011 19:06:05 UTC