Re: Again with the getIntersectionList()

On 2009-11-19 7:10 PM, Jeff Schiller wrote:
> On Thu, Nov 19, 2009 at 11:38 AM, Jonathan Watt <jwatt@jwatt.org> wrote:
> 
>>  * Would you really want 'pointer-events' to be taken into account?
> 
> nah

Is that an active "no", or "it wouldn't matter either way for my use cases"?

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

Same question.

>>  * Would you want elements that are fully inside the rectangle
>>   that you specify?
> 
> To me intersection should mean "does this element's area intersect
> with this other area".  It's not about whether it crosses this other
> border.  Thus, {x:20, y:20, width:20, height:20} intersects with {x:0,
> y:0, width:50, height:50}.
> 
>>  * Would you want elements that have overlap with the rectangle
>>   that you specify?
> 
> That's what 'intersection' means. I must have misunderstood you.

I'm not looking for use cases for getIntersectionList only, but rather for
getIntersectionList, getEnclosureList, checkIntersection, checkEnclosure, or any
other similar-but-different-in-details functionality. I'm trying to get a grasp
of specific things this "type" of behavior is useful for, and get people to
think about (and explain) the exact details of the behavior they'd prefer/need.

> If I am only able to get across one message to the WG it's this:
> 
> * getIntersectionList() and getEnclosureList() are the visual
> equivalent of getElementsByTagName/ClassName/etc.  SVG _is_ a visual
> language, right? :)
> 
> Letting developers query/filter elements is incredibly powerful.  See jQuery.

Putting on that hat, limiting the query to objects that are fully or partially
under a rectangle sounds very limiting. But what else would be desirable? Maybe
being able to pass in a string of path data (possibly limited to straight lines
for performance reasons) and ask for the elements that it intersects/overlaps?
Some other suggestions would be useful here.

Your comparison with jQuery is cute, and I do buy it to a certain extent, but
I'd also note that the performance concerns are vastly magnified in SVG. At each
element you're testing you're not simply looking at an attribute, but rather
doing expensive geometry calculations that potentially take into account
fill-rule, stroke-width, stroke-dasharray, stroke-linecap, stroke-linejoin,
stroke-miterlimit, stroke-dashoffset, clip-path, clip-rule, mask, markers,
filters, clipping, opacity, overflow, ... :-)

Jonathan

Received on Friday, 20 November 2009 01:18:23 UTC