Hi Jeff,
Jeff Rafter wrote:
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.
Yes, this is more or less what I was proposing. I would have used a WeakHashMap to maintain the correlation between referenced elements (key) and referencing element (element instance). Otherwise you would have to walk the subtree checking the correspondingElement. This does potentially cause memory issues - hence the WeakHashMap.
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...
What I was suggesting is that rather than creating a true clone (which is what we currently do) I was just going to have the ElementInstance tree. They would not copy the XML Attributes they would always fetch them from the corresponding element, but they would have a StyleMap (which is what the CSS cascade uses) which was derived off the use element.
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.
We don't need to copy the attributes over because the clone tree is a child of the use element so we don't need to copy the use style over into the subtree it just inherits via CSS as normal.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
