Re: hit testing and retained graphics

On Wed, Jun 29, 2011 at 4:30 PM, Matt May <mattmay@adobe.com> wrote:
> From: Tab Atkins Jr.
>> Can we please have a listing of the problems that are attempting to be
>> solved by the proposals beforehand?  It's impossible to evaluate a
>> proposal without knowing what it's trying to do, and how we'll know
>> when it's succeeded.
>
> It's actually pretty easy to go back into the archives and find the problems that need to be solved. Just search for "canvas 'doing it wrong'".

It is, unfortunately, not that easy.  (Out of curiosity, I did that
search.  The only threads returned were this one, and one about
resolution-independent drawing in <canvas>.)

You can't just state "canvas is inaccessible" and start designing
things to make it more accessible.  Poor accessibility is a series of
problems to be solved.  We need to state those problems, so we can be
sure we're solving them correctly.

I stated one such problem in a previous message in this thread,
generated from a helpful link from Charles Pritchard: "A user should
be able to indicate a portion of a complex image and get a caption
associated with that portion (possibly not visible in the image)."
This is a good problem - we can evaluate how useful it would be to
solve, can engineer solutions for it, and then compare how well
different solutions solve it.


> That's been the stock response to every case that can't be explained away easily. (Which is kind of funny when you think about it, since it was a spec that refused to render content to the user due to author error that was  responsible for the XHTML->HTML schism in the first place.)
>
> You can tell people they're abusing your spec all you like. And I'm sure it will be as great a success as when we all told people to stop using layout tables, and authors everywhere dropped their TRs and TDs immediately and sang Kum Ba Ya together in front of their laptops.
>
> No, wait. That didn't happen, did it? People kept on doing what they were doing because they, like browser vendors, have their time and money sunk in code they are reluctant to have to refactor. And so it will be with canvas.
>
> The sooner people here realize that "just use SVG" is not a valid solution to all cases, and that that means some kind of model for canvas accessibility is in fact needed to close the gaps (or pave the... how does that go again?), the sooner we can stop beating our heads against this brick wall.

I'm not 100% sure of the point you're trying to make, but if I'm
reading correctly, it's separate from what I'm talking about.

I think you're saying the same thing that Chaals did - people
apparently don't want to use SVG, even though it would solve many of
the problems they have, so we need to solve their problems in <canvas>
instead.

I can answer this the same way I answered Chaals: Yes, and?  The fact
that people want to use <canvas> does not imply that the best solution
is to graft a partial retained-mode API to the 2d context of canvas.
That's putting the cart *well* in front of the horse.  There are many
possible solutions, of which the aforementioned 2d context edits are
only one (and, imo, a particularly bad one).  We could, for example,
figure out why programming SVG sucks, and fix it.  We could make a new
context that is designed to easily handle the situation where you're
using <canvas> to design a prettier <form> or <input> (I outlined the
start of this idea in a previous email).  There are possibly other
solutions, and their goodness or badness depends on what problems
we're attempting to fix.

It is impossible to tell if a proposal is a good solution to your
problems if you don't know what problems you're trying to solve.

~TJ

Received on Thursday, 30 June 2011 01:10:05 UTC