W3C home > Mailing lists > Public > www-svg@w3.org > September 2010

expose <use> shadow tree for JS?

From: Declan Naughton <piratepenguin@gmail.com>
Date: Fri, 3 Sep 2010 19:35:21 +0100
Message-ID: <AANLkTimvTGs6LLZ+wjh9jW6nbxwpHyvOK=-Fs7z9mRUR@mail.gmail.com>
To: www-svg@w3.org
Hello,

As <use> clones elements on the dom level but does not expose their
javascript apis in any way, this makes it effectively useless to use <use>
to copy a group containing a canvas element (inside of a foreignObject
element (note this problem isn't related to foreignObject but the way that
the canvas api works)).

A workaround is to use <use> for all but the canvas content and manually add
the canvas using cloneNode, then using canvasElement.drawImage(origCanvas,
....). This may work for some cases, for more complicated scenarios (if the
canvas is under some elements and above others) we can discard using <use>
altogether and we get an even more complicated solution.

This does not just affect canvas use, but video controls, and other things
that are setup with javascript. Copying the state of objects isn't what I
have in mind (could this be a good idea?), but if the element apis are
available to JS we can re-initialize them, and keep track of them in our
scripts so that we can manually keep them in sync if that's the desired
effect (which actually seems like a bit of trouble - perhaps an option or
another element for syncing the *rendering* and interactivity of a container
should be discussed, more advanced than how -moz-element seems to operate*,
is this realistic?).

Has the WG discussed if something should be done in view of the
scriptability shortcomings wrt how <use> is defined? What are the downsides
of exposing the shadow tree in some way? Canvas being such an important api
nowadays, it isn't good to learn that it cannot work with <use>.

Regards,
Declan


* http://hacks.mozilla.org/2010/08/mozelement/
related mozilla bug discussion:
https://bugzilla.mozilla.org/show_bug.cgi?id=579853
Received on Saturday, 4 September 2010 13:09:09 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:46 GMT