On Tue, Jul 12, 2011 at 4:52 PM, Doug Schepers <schepers@w3.org> wrote:
> Robert O'Callahan wrote (on 7/11/11 11:52 PM):
>
> I don't understand #3 very well, partly because it's not specified how
>> those
>> elements would participate in rendering. Why not just put the SVG elements
>> over or under the canvas? They'll be rendered and accessible.
>>
>
> As I understand it, once the user is in the subtree, they will need to get
> at the elements in question (and thus the geometry) as part of the current
> focus ring. There seems to be a need to add them into this navigation order
> by inclusion or reference. It's possible that's not a critical aspect of
> what Charles and Rich proposed, but that was my reading of it, so this
> aspect of the proposal was aimed at that (though I do mention I saw it as
> optional).
>
> Rendering the SVG above or below the canvas, as appropriate, would
> otherwise solve that geometry problem. Rendering it below the canvas would
> effectively act as a image map, I guess, but maybe with more interaction
> possible?
Canvases can be transparent so putting content below the canvas can make
sense.
Tab order is an issue, but doesn't canvas shadow content participate in
tabindex tab order with the rest of the document? If so, authors can solve
it with tabindex.
> #2 could be addressed by extending SVG stroke and fill values to include
>> arbitrary CSS image values, and using the element() image value to refer
>> to
>> a canvas. I think that feature would be useful in many ways, and I'd be
>> interested in supporting it.
>>
>
> That's an interesting specific proposal, thanks. We'll talk about that at
> the SVG F2F at the end of July. If you have more details or have time to
> tinker around with that, I'm interested to hear more about it.
Fit the CSS image to the SVG bounding-box for the stroked/filled shape.
There's some vaguely related discussion here:
http://www.w3.org/mid/BANLkTinNZs-1uoF4jaspJJMug14=5sYTShaFh5C4sLBdQxTRow@mail.gmail.com
> I think #1 can be quite easily implemented as a JS library. I'm not
>> convinced it would be necessary to provide direct browser support.
>>
>
> Yeah, I kinda did this already [1], and Charles and others have attacked it
> the reverse direction. SVG needs a new API anyway, since as Tab mentioned,
> the DOM API is pretty lousy. Having it as a script library doesn't solve
> the marshalling problem between script engines and the DOM, so it doesn't
> help SVG's performance (though that's not a Canvas problem). If we could
> benefit from a new API anyway, why not kill two birds with one stone?
>
I'm just not sure the canvas API is the right solution to fixing the SVG DOM
API issues.
For example, another approach to improving the SVG DOM would be to introduce
new methods on SVG elements, e.g. compare
var ctx = document.getElementsByTagName("canvas")[0].getContext("2d");
ctx.fillStyle = "red";
ctx.fillRect(100, 100, 200, 200);
vs
var svg = document.getElementsByTagName("svg")[0];
svg.appendRect(100, 100, 200, 200, {fill:"red"});
Rob
--
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]