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

Re: Again with the getIntersectionList()

From: Andreas Neumann <a.neumann@carto.net>
Date: Sat, 7 Nov 2009 09:25:19 +0100 (CET)
Message-ID: <57512.141.244.176.189.1257582319.squirrel@webmail.carto.net>
To: "Jeff Schiller" <codedread@gmail.com>
Cc: "www-svg" <www-svg@w3.org>
Hi Jeff,

I am glad that you are taking on the task of implementing this very useful
method to fill the gap until implementors are natively implementing the
method.

On the other hand this should really be natively implemented in all
compliant viewers. I guess every implementor already has the prerequisites
for this method, since they have to do hit-testing for graphical elements
anyway ... so it is mainly a matter of testing not only the top elements,
honoring the pointer-events attributes.

So is it mainly webkit and Firefox that do not implement the methods? Are
bugs filed?

Andreas


On Sat, November 7, 2009 3:54 am, Jeff Schiller wrote:
> 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?
>
> Thanks,
> Jeff
>
>
> On Fri, Nov 6, 2009 at 8:50 AM, Jeff Schiller <codedread@gmail.com> 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]
>> http://www.w3.org/2003/01/REC-SVG11-20030114-errata#liveness-getintersectionlist-getenclosurelist
>> [2]
>> http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObject/struct-dom-11-f.html
>> [3] http://lists.w3.org/Archives/Public/www-svg/2004Oct/0007
>>
>
>


-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/
Received on Saturday, 7 November 2009 08:26:15 GMT

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