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