- From: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
- Date: Wed, 06 Oct 2004 08:50:01 -0400
- To: www-svg@w3.org
Hi all, I am attempting to implement getIntersectionList and getEnclosureList in Batik in doing so it seems that the current specification of these methods is fairly incomplete. So I thought I would ask for clarification and make suggestions on how the specification could be improved. ---- Questions: Q: Does the NodeList returned include grouping elements (svg, g)? A: I say no as these elements do not generate 'pointer-events' which these methods appear to be modeled on. Additionally in cases where a person is interested in particular group elements they can 'discover' these by checking the ancestors of the elements returned (it's a little trickier for enclosure - although in this case getBBox can be used). Q: The spec uses the term 'rendered content'. This makes me wonder if filters are to be included? A: Once again I would say no. The two viable options would be some sort of 'threshold' on the alpha channel of the filter result (extremely expensive) and just using the filterRegion (often silly). I say just use geometry, as most pointer-events implementations do. Q: 'referenceElement' It says elements whose drawing order has them below the given element - is this really intentional? A: When I first saw the method I thought this was the root of a subtree to search (which I mention to setup the next question). Also as way of clarification, I assume that children of the referenceElement are considered for intersection/enclosure (in other words the check is postfix not prefix). This would be consistent with rendering order as described in 'enable background'. Q: Speaking of the root of the subtree to search. Is the search restricted to the children of the svg element the method is called on? A: I say yes, because the rect is taken to be in that svg element's coordinate system, indicating that the search is 'associated' with the svg element the method is called on. It also offers a reasonable (although not great) way to enable authors to restrict the search to a reasonable subset of the document (ignore a background or foreground layer), this I think is essential for this method to be useful in the 'real world'. Q: For a Use element should it return the ElementInstance's or just the 'use' element? A: Once again because this is modeled on pointer-events, I would think that it would be correct to return the ElementInstances. If the WG decides that the 'use' element should be returned, should the check just use the 'use' elements BBox or should it inspect the content? Q: For Text should it return tspan elements? In the case of a tspan and data from text should it return both? just the text node? A: I would think that it should return text and tspan elements. This is a bit of an odd case (since a parent and it's child can be returned) but text is just odd to begin with :). I think this is also most consistent with the 'pointer-events' model (as if you clicked on every point in the rectangle).
Received on Wednesday, 6 October 2004 12:50:04 UTC