- From: Doug Schepers <schepers@w3.org>
- Date: Fri, 13 Nov 2009 03:49:26 -0500
- To: www-svg <www-svg@w3.org>
- CC: Jeff Schiller <codedread@gmail.com>
Hi, Jeff- Jeff Schiller wrote (on 11/12/09 9:28 PM): > On Fri, Nov 6, 2009 at 8:50 AM, Jeff Schiller<codedread@gmail.com> wrote: >> 2) There has been feedback that the second parameter to these >> functions is not clear [2]. I would agree with that feedback. >> >> "only return elements whose drawing order has them below the given >> reference element" >> >> This suggests the painters model to me. However, it is not clear why >> this is useful. >> >> It seems that Opera may have implemented it as the root of the subtree >> that should be searched. Erik, can you confirm? >> > > Can someone please clarify for me what the second parameter in > getIntersectionList() is? If not, can it be added for your next > telcon agenda? According to SVG 1.1 [1]: [[ getIntersectionList Returns the list of graphics elements whose rendered content intersects the supplied rectangle, honoring the 'pointer-events' property value on each candidate graphics element. Parameters in SVGRect rect: The test rectangle. The values are in the initial coordinate system for the current 'svg' element. in SVGElement referenceElement: If not null, then only return elements whose drawing order has them below the given reference element. Return value NodeList: A list of Elements whose content intersects the supplied rectangle. No Exceptions ]] So, the first parameter is an SVGRect object (not an element), while the second parameter is a reference to an element that allows the author to filter the results by their document order. This seems like a strange API design to me, though actually it could be useful. Consider a few examples of use, given this fragment (note that I'm using <rect> elements for clarity, but it could be any elements): <svg xmlns="http://www.w3.org/2000/svg"> <rect id="r1" x="5" y="5" width="40" height="40"/> <rect id="r2" x="105" y="105" width="40" height="40"/> <rect id="r3" x="5" y="5" width="40" height="40"/> <rect id="r4" x="5" y="5" width="40" height="40"/> <rect id="r5" x="5" y="5" width="40" height="40"/> </svg> A) SVGRect1 {x:20, y:20, width:0, height:0} getIntersectionList( SVGRect1 ); This is essentially a point that will return everything that intersects that point, regardless of document order; thus, it will return r1, r3, r4, & r5. It will not return r2, because that rectangle doesn't intersect that point. This would be useful for getting every element at the coordinates of a mouse click, for example. B) SVGRect1 {x:20, y:20, width:100, height:100} getIntersectionList( SVGRect1 ); This is a rectangular area that will return everything that intersects that area, regardless of document order; thus, it will return all of the rectangles, because it intersects them all. This would be useful for finding elements inside a certain viewport (either a real viewport as established by an <svg> element, or a virtual one created by a clipPath, etc.). C) SVGRect1 {x:20, y:20, width:0, height:0} getIntersectionList( SVGRect1, r4ref ); This is the same as (A), but with the constraint that it only returns those elements that come before r4 in document order; thus, it will return r1 & r3. It will not return r5, because that rectangle comes later in document order. This would be useful for getting every element below the event target element (e.g. r4) at the coordinates of a mouse click. Not exactly the way I would have designed it, but it still has sensible use cases. [1] http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#InterfaceSVGSVGElement Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Received on Friday, 13 November 2009 08:49:36 UTC