W3C home > Mailing lists > Public > www-svg@w3.org > November 2009

Re: Again with the getIntersectionList()

From: Doug Schepers <schepers@w3.org>
Date: Fri, 13 Nov 2009 03:49:26 -0500
Message-ID: <4AFD1D96.70409@w3.org>
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 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:43 GMT