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

Received on Thursday, 30 June 2011 20:32:02 UTC