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

Again with the getIntersectionList()

From: Jeff Schiller <codedread@gmail.com>
Date: Fri, 6 Nov 2009 08:50:14 -0600
Message-ID: <da131fde0911060650t65eb0123vbffabbd4708fc26e@mail.gmail.com>
To: www-svg <www-svg@w3.org>
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

    "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?


[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
Received on Friday, 6 November 2009 14:50:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:24 UTC