W3C home > Mailing lists > Public > www-svg@w3.org > October 2003

Intersection without Rects

From: Gavin Kistner <gavin@refinery.com>
Date: Wed, 1 Oct 2003 14:39:42 -0600
To: www-svg@w3.org
Message-Id: <62B4A0A8-F44F-11D7-AF3E-0003937E984E@refinery.com>

Rather than
	SVGSVGElement.checkIntersection(element, rect)
and
	SVGSVGElement.getIntersectionList(rect, referenceElement)
(which I would only find moderately useful in any UA that supported 
them) I would really like to see

==================================
SVGLocatable.intersects(element)
element - A SVGLocatable element to check against the current element
returns - true if the source element intersects the parameter element, 
false otherwise
==================================
SVGLocatable.intersectsElements(parentElement)
parentElement - the SVGLocatable container element to which the search 
should be constrained.
	If null, the entire document is searched.
returns - a dom::NodeList of all elements which intersect the calling 
element
==================================

Restricting the intersection check to simply a SVGRect may make it a 
little easier for the UA developers, but fails to address a large 
number of programming needs necessary for SVG to be a rich interface to 
programming.

I have never written an SVG UA before, but I (naively?) imagine that 
implementing these arbitrary intersection checks would be only a trifle 
more difficult for the UA developers. I would think that they would 
already have such algorithms written for the optimization of drawing, 
anyhow. (Having them overlap on the screen, to screen-px precision, 
would likely be sufficient for the majority of applications.)

If backwards compatibility is important enough, the spec could persist 
in its current not-very-oop design of calling these methods off of the 
SVGSVGElement, and simply expand the type for the current 'rect' 
parameter to be SVGLocatableElement.

(Aside: should the 'element' and 'referenceElement' parameters above 
really be SVGElement, as the ECMAScript binding currently specifies, or 
should they be SVGLocatable (or even SVGTransformable)?)
--
Gavin Kistner @ Refinery, Inc.
gavin@refinery.com
work: +1.303.444.1777
cell: +1.303.641.1521
Received on Wednesday, 1 October 2003 16:39:44 GMT

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