Re: hit testing and retained graphics

On 7/8/2011 11:35 AM, Tab Atkins Jr. wrote:
> On Fri, Jul 8, 2011 at 9:08 AM, Richard Schwerdtfeger<schwer@us.ibm.com>  wrote:
>> From: Doug Schepers<schepers@w3.org>
>>> Charles Pritchard wrote (on 7/6/11 3:07 PM):
>>> Browser vendors have not pushed back on "supporting a11y for canvas
>>> content", they have pushed back against adding a retained-mode component
>>> to the Canvas 2D API, for obvious reasons: the Canvas 2D API is intended
>>> for *immediate-mode* graphics, and we already have a 2D graphics
>>> standard for the Open Web Platform: SVG.
>
>> 2. we are roughly 1 feature away from fixing
>> canvas accessibility.
> No we're not.  Not by a long shot.  I've given several reasons why not
> in the past.
Citation please. I haven't seen these -several- reasons that we're far 
away from canvas a11y.

A11y itself is a huge field ready for innovation; we're not able to come to
those innovations while we're still fighting for the basics, like 
bounding boxes.

Canvas a11y has been under discussion since 2009, these issues have not
been shifting... they're the same ones as they were back then, for the same
set of software and tools there were back then.

We've addressed most of the issues, Richard has personally spoken
with several AT vendors about it, and I've done the code
and AT testing across Windows, OS X and Mobile Safari.

These are reality-based actions. I'm fine exploring theoretic problems,
I'm happy to do that, but I'd like there to be a distinction and recognition
of the work that has been done.

>> The smoothing of shapes has nothing to do with retained mode.
> Um, it has everything to do with retained mode if you want it to be
> automatic.  By definition.
Again, automatic is a strange term that keeps coming up.
In css you can set something to 100%, which makes it "automatic",
whereas with canvas you do need to monitor for resize events
and gather various metrics to have the same result.

But gosh that's really common for canvas. It's a low level API.


>> What we are
>> trying to do is make canvas accessible. SVG is another technology and that
>> is a separate accessibility effort.
> Conway's Law strikes again.
This is a subtle put down; I get it, but it's absurd.

You're telling us that, because our teams are using canvas, and have 
come to
us with issues regarding canvas, that we've become deluded.

As it happens, Canvas is a low level API, and SVG a high level format.
We're trying to fix the low level API before taking on the high level 
format.

SVG is implemented atop 2d apis just like Canvas -- it can even be 
implemented in Canvas,
though there are some features which are difficult... the same is true 
of existing SVG
implementations anyway, there are many features which have been skipped 
or are
quite difficult.

Personally, I try to solve the core issues first, then move on to more 
fancy-stuff.

>> If SVG is so wonderful why are you not
>> pushing for an SVG element in HTML 5?
> SVG is in HTML.<http://whatwg.org/html#svg-0>
More appropriate link:
http://www.w3.org/TR/html5/the-map-element.html#svg-0

SVG is mentioned in HTML. Processing is not specified in that document.
Object tags are mentioned in HTML as well, that doesn't mean that Java
is part of HTML5.

Regardless, I think SVG is wonderful, and I'd rather be spending my
time addressing issues on SVG. But I'm stuck here, in the low level
API, until the foundation is solid.

There's a very near and dear issue to me with SVG, and that's
the capability to display InkML rendering. SVG is currently quite poor
at handling pressure values on lines, and using repeated elements
really takes a toll on most implementations.

>> Why have you not pushed to ditch
>> canvas from HTML in favor of SVG?
> Because that would be a stupid thing to push for, frankly.  Doug's a
> smart guy.  He recognizes, like everyone else, that immediate mode
> APIs have an advantage over retained mode APIs in some circumstances.
There's WebGL, a mix of immediate and retained mode API; keep that in mind.
It works because it should. It's closer a format for efficient InkML 
processing
than either Canvas or SVG.


Again, we're looking at low level API and high level format;
this confusion over retained mode is a red herring.

>> Finally, on this point. When a developer picks a technology they do it based
>> on a number of factors. Canvas already has been used my many open web
>> applications. It needs to be able to support accessibility if this is the
>> developers choice.
> Please see Jonas's post for a well-written response to this point.  I
> have also responded to this in depth in previous emails.
>
> (One cogent reason developers choose canvas is that it's easy to use
> to get pixels on the screen.  Building SVG from script is really
> painful.  This is just an API problem, though - we all know that the
> DOM is a *horrible* API.  If someone were to make a pretty API for SVG
> that's well-designed for Javascript - something like paper.js - I
> believe this situation would change drastically.)

Doing document.getElementById('tagId') is a lot lengthier than doing 
$('tagId'),
but we've got a scripting environment for those cases.

We're not held-up by the verbosity of SVG -- there are Canvas to SVG 
output scripts,
just as there is a Canvas to VML output script.

We are held up when something -can-not- be expressed. As this is a 
communication medium,
I am very sensitive to that fact.

-Charles

Received on Friday, 8 July 2011 20:39:24 UTC