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

Doug: would you explore the proposal a little further "in code" with me?

Current tag soup problem (legacy):
<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>

Canvas native solution:
<canvas><button id="myButton" /></canvas>
canvasContext.setElementPath(myButton)


Canvas+SVG profile:
<canvas>
<path d="M... z" aria-owns="myButton" />
<button id="myButton" />
</canvas>

With path being injected via something like:
canvas.appendChild(canvas.getContext('svg').rect()).setAttribute('aria-owns','myButton');

Is it something like that?

-Charles

On 6/30/2011 3:11 PM, Richard Schwerdtfeger wrote:
>
> 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
>
> Inactive hide details for Charles Pritchard ---06/30/2011 03:34:54 
> PM---On 6/30/2011 9:18 AM, Tab Atkins Jr. wrote: > This is wCharles 
> Pritchard ---06/30/2011 03:34:54 PM---On 6/30/2011 9:18 AM, Tab Atkins 
> Jr. wrote: > This is why I keep pounding on the "define the problem
>
> 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
>
>
>