Re: You Got Your SVG in my Canvas! Mmm, Delicious!

I would like to try and see how far we can take Doug's proposal.

If we can produce SVG retained mode graphics and bind them to canvas
elements in the subtree that would be fine. ... However, at the end of the
day I suspect that groups of SVG drawing objects used to form a semantic
entity that are backed by the canvas fallback content would need to be
entirely drawn using SVG.

As far as SVG's shadow DOM I have not looked at it yet.

Rich

Rich Schwerdtfeger
CTO Accessibility Software Group



From:	Charles Pritchard <chuck@jumis.com>
To:	"Tab Atkins Jr." <jackalmage@gmail.com>
Cc:	Richard Schwerdtfeger/Austin/IBM@IBMUS,
            public-canvas-api@w3.org, public-canvas-api-request@w3.org,
            Doug Schepers <schepers@w3.org>
Date:	06/30/2011 03:34 PM
Subject:	Re: You Got Your SVG in my Canvas! Mmm, Delicious!



On 6/30/2011 9:18 AM, Tab Atkins Jr. wrote:
> This is why I keep pounding on the "define the problems you're solving
> first" thing.  You keep trying to jump straight to the solution.  Your
> #1 and #3 are good problems to solve.
>
> Note that your #2 is suggesting that, based on history, a correct
> solution is likely going to be based on a retained-mode API.  *I 100%
> agree.*  However, without a proper list of problems, there's no way to
> evaluate the possible solutions.  They may not even all be solved by
> the same thing.

There is already a retained-mode API in place -- that's why we keep
circling back to it.
I'm working to get you the use-cases in the format you've requested..
But I just
want to slow the discussion down, as "retained-mode" seems to have
reached a semantic overload/
satiation.

We have a retained mode within the shadow DOM, which can be updated via
immediate-mode Canvas calls.
<canvas>
<button id="myButton" />
</canvas>

The shadow dom retains all the attributes of sub-nodes, including event
handlers,
ids and the like. Canvas can go ahead and signal to UA that a
retained-element
has a particular path, via drawFocusRing(element). At that point, it's
still the UA
and the sub-DOM that are doing all of the retaining of information.
Canvas does not.

Richard has suggested that the sub-DOM also retain information relating
to paths
and bounding boxes. It would be the sub-DOM nodes that retain this
information --
when the A11Y APIs on the UA/OS go ahead and peek at an element in the
subDOM,
such as the button, they are going to get a response that lets them know
what
the bounding box of that button is..  That bounding box can be set, via
immediate
mode calls, via Canvas.  That's very similar to drawFocusRing.

drawFocusRing and associated caret apis enabling keyboard device a11y;
the problem is that we need to enable pointer device/spatial a11y for
the shadow DOM.

One way or another, we need to enable a situation where a Knowing developer
can bind an object in the subdom to a bounding box in the Accessibility
Tree,
as well as stash path information, for spatial ATs.

It is quite possible to overlay CSS boxes and SVG elements
transparently, atop
or below the Canvas element being used.. But the costs of doing so are
truly
prohibitive for developers.

Stringify methods for canvas would lower the cost, a little, but it
would still result
in a very nasty tag soup... Stringify would enable devs to getCSSMatrix
to transform
bounding boxes, and getCurrentPath to copy path data to svg path elements.
Again though... nasty tag soup.

We're hoping to avoid such a bitter meal, where three elements are required
to define the path.

This is what I do not want to do or deal with, as a developer, or an AT
designer:

<div id="tagSoup">
<div style="width, height, x, y; position: absolute;">
<svg style="position: absolute"><path d="M..... z;" /></svg>
<canvas><button id="myButton" /></canvas>
</div>

It's pretty clear that should just be:
<canvas><button id="myButton" /></canvas>
With  context.setElementPath(myButton) run at the appropriate occasions.

It is not practical for developers to execute the tag soup example.
The stringify supplemental I put in my proposal would make it practical,
but it'd still be a sad situation.

-Charles