[SPEC] getIntersectionList, getEnclosureList.

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