Hi Thomas
I would not say there was a major hurdle to overcome. It just hasn't been a major issue to date.
That is good to know!
This would provide the basic DOM interface. There would be a bit of an issue with changes because the current way Batik handles updates to a used subtree is to recreate the entire subtree. This would likely mess up the element instance tree mapping. This probably isn't a big deal for most cases but could cause some problems.
I think in general it is sub-optimal but a workable solution (the method you propose lower is much better).
So far GC shouldn't be an issue, as long as the ElementInstance tree is released in the dispose method of the SVGUseelementBridge. It's usually when you get to event listeners that you get memory leak issues...
Sounds good.
This is getting to the tricky bit. My intent was to kill two birds with one stone. I was going the have the ElementInstance (or a peer of it) be a 'special' Element that got all DOM attributes from the referenced element but used the 'use' element as the 'source' of it's CSS cascade. This 'special' element would then be the one associated with the GVT node. Thus when the 'real' node triggers a mutation event a matching event would be triggered on the 'special' element (I can think of several ways for this to happen, the cleanest would be to have one 'capture' event listener associated with the 'use' element on the used element's document root).
This sounds excellent. A low-end solution would be to simply handle the four mutation events inside of the use element and pass them (propagate) into the <use>d element in the shadow tree via getInstanceRoot().correspondingElement.
This would allow the use element to really track modifications and avoid the need to rebuild the entire subtree. It would also avoid the subtree clone nonsense, and fix the conformance issue.
I think in either case the subtree has to be cloned (at least initially). Primarily because the attributes inherited from the <use> still need to be attached to the subtree (different for each reference to the element). Also, it is possible to make modifications to the subtree that need to be known to the use... I will try to find a good example of this...
The other factor is the need to support 'shadow' trees for sXBL. Which I think will need some of the same sorts of features although Cameron is the expert on this.
Good to know-- in general I despise shadow trees.
Why do you think it needs a 'g' if the use element is referencing a single element I don't see the need.
This is primarily from reading http://www.w3.org/TR/SVG/struct.html#UseElement#UseElement In the "Otherwise:" section. But now on re-reading it I suppose that it could be interpreted differently: e.g. it is recommending a way to handle the visual appearance-- but in reality there is no need to wrap with a <g>. In effect though I find it easier to wrap the element in the <g> because of attributes like style. If there is a style attribute in the <use> and in the referenced element that set different properties, overwriting the referenced element's style attribute is bound to lose information.
I'd be happy to help but to contribute this back you would need to have a CLA on file.
Alright... I will look into that.
Thanks, Jeff
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
