Re: expose <use> shadow tree for JS?

Hello,

I wish to share with you some thoughts about the SVG 'use' element when it
is about dealing with HTML elements because I faced the same problems as
Declan (and I don't think we will be the only one).

I'm web designer/developer and I found that there is a small flow here in
the SVG spec.

The SVG 1.1 spec is pretty clear on how the CSS and the DOM event act
between the original elements and the duplicate elements but nothing is said
about calling the JS APIs of the original elements.

As a end user, I found really intuitive to assume that any call to the
original elements and their contexts should be replicate all along the
duplicate elements available in the document, especially when we talk about
the HTML 'canvas' element. Unfortunately, at that point, it is not the
behavior the browser vendor have choosed. After some discussions with the
mozilla team, it seams that they choose to do nothing because they assume
that the 'use' element perform an hidden cloning operation and that kind of
operation does not clone the back end context of the elements (more about
that discussion here :
https://bugzilla.mozilla.org/show_bug.cgi?id=579853this bug is the
same concern I share with Declan here). I desagre with that
interpretation because the spec talk about an "as if" operation not an exact
clone operation. The CSS and Event specificity comfort me in my way of
thinking.

I think at that point that my interpretation (any call and context should be
replicate) and the Mozilla interpretation (which seems to be the common
case) are both right and it seams necessary to clarify the spec here.

I don't agree with Declan about exposing the shadow DOM tree because it is
possible to perform a DOM cloneNode operation to do it and it is not the
spirit behind the 'use' element.

My opinion is that the use element should act as follow :

   1. Any API script call made on an element part of the original tree
   should be replicate as is on the duplicate trees.
   2. Any existing context on the original tree should be duplicate in it's
   current state to the corresponding elements in the duplicate trees
   3. Any change made on a duplicate element context should be replicate on
   the original tree and all other corresponding duplicate elements

The first point is important to handle element such as 'video' or 'audio'
(for example to be sure to have a synchronized play/pause action between a
original element and all it's pseudo-clone) or if developers want to extend
some DOM element by themselves.
The second point is important for the 'canvas' element to be sure that any
further change in the canvas context will be shared between all the
duplicate canvas at any time (for browser vendor, this could be achieve by
sharing a single context through multiple canvas element... but it could be
tricky to handle this on any arbitrary element. For example, I can't imagine
the problems with custom build elements made with XBL)
The third point is important to make clear that any form element duplicate
in that way is not a new form element but a simple interactive
representation of a single form element. Maybe my sentence it's not very
clear but it does not have to hurt the DOM event handling already defined
for the duplicate trees. It's a way to say that if you type some characters
in a duplicate input text element, the value of the  original element must
be change as well.

So here's my thought. What do you think ? Am I definitively wrong or do the
SVG implementors could consider that proposal ?

Regards,
Jeremie Patonnier


2010/9/3 Declan Naughton <piratepenguin@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