xmlgraphics-batik-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McCormack <cam-batik-...@aka.mcc.id.au>
Subject Re: Performance of Batik.dom.svg.SVGOMDocument.getById()
Date Sun, 29 Aug 2004 01:33:25 GMT
Thomas DeWeese:
>    One other thing occured to me on this point.  You need to
> look out for is SVGOMCSSImportedElementRoot this is used for
> the 'use' element where we clone the referenced content into
> the referencing document, obviously the id's from these
> cloned subtrees shouldn't be counted.  Just trying to
> make it interesting ;)

Yes, good point.  With my current implementation this isn't a problem
since the SVGOMCSSImportedElementRoot never gets appended to the actual
document tree.

I have though an SVGOMCustomElement class that lets foreign namespace
elements have shadow trees and I use a SVGOMCSSImportedElementRoot there
too.  But in this case the id attributes do need to be checked for, so I
neded up specifically checking for such elements when adding and
removing subtrees to the document so that it would recurse into the
shadow trees.  Not very nice.

I had wondered for a while whether elements with id attributes in shadow
trees should be found by getElementById.  The shadow trees aren't really
in the document tree, so I guess they shouldn't.  ASV6 does.  Now that I
know of the existence of SVGSVGElement.getElementById I suppose that is
what one should use inside shadow trees.  It would mean though that
authors would have to put an svg element explicitly in their shadow
trees if they want to look up elements by id.


Cameron McCormack
|  Web: http://mcc.id.au/
|  ICQ: 26955922

To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org

View raw message