Re: Again with the getIntersectionList()

Hi Jeff,

--Original Message--:
>Another confirmation.  The method getIntersectionList(rect):
>"Returns the list of graphics elements whose rendered content
>intersects the supplied rectangle, honoring the 'pointer-events'
>property value on each candidate graphics element."
>So if I have a circle whose pointer-events="stroke" and then I call
>getInsersectionList(rect) where rect is in the center of the circle's
>fill but does not intersect with the circle's stroke, then that circle
>will not be part of the returned NodeList, correct?

Sounds correct to me. Well spotted.


>On Fri, Nov 6, 2009 at 8:50 AM, Jeff Schiller <> wrote:
>> I am trying to determine a few things about getIntersectionList() on
>> the SVGSVGElement interface. I would like to implement these functions
>> in WebKit and Gecko.
>> 1) It seems that the WG has clarified that the NodeLists returned by
>> getIntersectionList() and getEnclosureList() are to be static and not
>> live [1] [2].  Just wanted confirmation.  Please say yes :)
>> 2) There has been feedback that the second parameter to these
>> functions is not clear [2].  I would agree with that feedback.
>> It also may be that Batik implemented it this way.  This seems more
>> sensible to me than looking at the painters model.  Has it been
>> clarified in the errata or upcoming Second Edition?
>>    "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?
>> What did Batik finally implement?
>> I would personally think that the subtree search is more useful than
>> the painters model.  If verbage were to be updated, here's my first
>> attempt:
>>    "only return elements that are in the subtree whose root is given
>> by the reference element"
>> 3) Can a suitable test be added to the SE test suite using the second
>> argument in those functions?
>> Thanks,
>> Jeff
>> [1]
>> [2]
>> [3]

Received on Saturday, 7 November 2009 03:28:29 UTC