Re: Again with the getIntersectionList()

On 2009-11-06 3:50 PM, Jeff Schiller wrote:
> 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 :)

yes

I'm curious what use cases people see for functionality along the lines of
getIntersectionList/getEnclosureList. In any use case you may have:

 * Would you want to get elements that are "below" a given element
   in rendering order, or would you rather want elements that
   are descendants of a given element.

 * If you want the elements that are "below", should 'z-index' be
   taken into account in deciding what's "below" an element, or
   do you really just want "comes before in document order"?

 * Would you really want 'pointer-events' to be taken into account?

 * Would you want 'visibility' or 'display' to be taken into account?

 * How about opacity, markers, masking or filters?

 * Would you want elements that are fully inside the rectangle
   that you specify?

 * Would you want elements that have overlap with the rectangle
   that you specify?

 * Would you only want elements that intersect with the *edges*
   of the rectangle that you specify (i.e. not elements that are
   fully inside)?

 * Would bbox intersection checking be sufficient?

Of course I'd be most interested to hear of *specific* things that people have
actually found themselves wanting to do but couldn't (or not well) because of
the lack of getIntersectionList/getEnclosureList or similar in SVG implementations.

The use case I see for getEnclosureList is implementation of a selection tool in
online SVG editors. I wonder if taking stroke into account in necessary though,
or if bbox calculations (only taking fill into account) would be sufficient. I
think bbox would probably be okay.

The use case I see for getIntersectionList is again online SVG editor specific:
image copping. When cropping an image you'd want to throw away any elements that
are fully outside the bounds of the SVG image to save space. In this case
though, you'd not only want to take into account stroke, but also marker,
filter, and anything else that increases the bounds of a graphic element over
stroke bounds. getIntersectionList doesn't take this into account though, and
therefore doesn't satisfy this use case. Maybe cropping optimization is better
done on the server?

So neither of these use cases are strongly completely to me for
keeping/implementing getIntersectionList/getEnclosureList. Any better ones? :-)

Jonathan

Received on Thursday, 19 November 2009 17:39:09 UTC