Cameron McCormack wrote:
Thomas DeWeese:
Well, yes and no. If we fire that event the event target should be
an ElementInstance. Since as you know we don't implement the
ElementInstance
stuff it would be difficult to do this :) It isn't clear to me which is the
lesser of the two evils - not firing the event, or firing the event with
the cloned instance as target.
Hmm, I see the problem. I thought the SVGElementInstance was just an
interface, and that the shadow tree contained actual SVG graphics object
elements which implement that interface. But if they are completely
separate objects, I can see the problem.
Am I right in thinking that, since the shadow tree is completely hidden,
it's impossible to modify the instantiated objects? And that you can
only modify the referenced elements?
You are correct. If you modify the element referenced from the
ElementInstance all use's of that element will be changed (or at least
_should_ be changed).
Anyone willing to vote on this :)
Maybe the objects which have been cloned with the deepCloneNode function
should implement SVGElementInstance. Maybe newNode can be overriden
in non-abstract descendants of SVGOMElement to do
return new SVGOMBlahElement implements SVGElementInstance { };
in the right situation, or something.
Well this is getting close to my thinking on how to actually fix the
use issues. Essentially you would create an ElementInstanceElement that
would wrap the ElementInstance so we can build our Rendering Tree normally,
it would do all the proper 'funky stuff' for CSS and would forward
getAttribute requests to the underlying element. It could also register
CSS and dom change listeners that it could use to propogate changes back to the
bridges in the use tree.
It's not a _huge_ amount of work but I supect there would be more
than a few devils in the details.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
