Re: hit testing and retained graphics (resending)

Hi, Rich-

A few points in reaction to your recent emails:

1) It is inappropriate for you to question people's motives as part of 
your argument; you did it to Tab when he was trying to solidify 
use-cases and requirements, you've done it with others, and now you've 
done it with me.  This is classically called an "ad hominem" fallacy... 
it is inappropriate not because it's rude (though it is), nor because it 
decreases the technical level of dialog (though it does), nor because it 
tends to deafen you to the points the other is making (though it does), 
but because it does not refute or even address the technical merits of 
the other's position.

2) I have no concern about people using SVG.  They will or will not 
based on the specific use case.  Perhaps a few years ago, I would have 
been more concerned, but now SVG is supported in all major browsers, and 
it is very unlikely to be removed; we have all the major browser vendors 
and key authoring tool vendors participating in the SVG WG, and we are 
working closely and productively with the CSS WG.  SVG works with HTML5 
in all browsers, and we will continue to make improvements in that 
integration; we also have specific plans for improvements in SVG's 
accessibility, including (but not limited to) extensions of ARIA.  SVG 
is doing just fine.

3) You are apparently confused about certain aspects of SVG, and have 
clearly not understood my proposal, nor understood browser vendors' 
responses to certain aspects of it.  I did not suggest, as you seem to 
think, replacing the whole set of "subtree/shadowtree" accessibility 
hooks, but rather suggested how SVG could be used with that subtree as 
the locative aspect of certain visual features, rather than inventing a 
whole new retained-mode API or markup, which browser vendors have 
already rejected.

4) I realize that you are trying to help accessibility, but the solution 
you are advocating is an ungainly hack that is unlikely to grow to meet 
the real needs of authors and users that will arise as they start to use 
it in depth.  You keep saying that you are "roughly 1 feature away from 
fixing canvas accessibility"... and you always will be, because you are 
patching the obvious flaws, not the ones that will arise like zombie 
whack-a-moles.

5) I've taken time out of my extremely busy schedule to try to help find 
a third path here, between your retained-mode canvas extensions and 
browser vendors' proposal that authors use SVG for those cases instead, 
because I care about graphics accessibility.  I think that a shared 
Canvas-SVG 2D graphics API is desirable for general use, and also 
happens to address the specific use cases you seem to have expressed for 
the problem at hand [1]; the SVG WG will be working on this SVG-Canvas 
integration at our next F2F this month in any case.  You don't seem to 
agree currently that this is a good solution, citing that certain parts 
of it need to be defined and implemented (which we agree on), but seem 
to overlook this same flaw in your own proposal (along with the added 
disadvantage that browser vendors have said they will not implement your 
proposal).  But I have neither time nor inclination to quibble with you. 
  If you change your mind, and want to develop the Canvas-SVG idea 
further, I'll be happy to help.  If not, I wish you luck in finding 
another solution that meets your use cases and is acceptable to 
implementers.

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

Regards-
-Doug

Received on Friday, 8 July 2011 18:18:28 UTC