Re: Intersection without Rects

By the way, while not mentioned below explicitly, the same desire (to 
have rect-less intersection and intersectionList methods) applies to 
enclosure. And given the conceptual addition of hierarchy for 
enclosure, IMO there should be a doubling of methods, at least 
certainly on the list side:

SVGLocatable.encloses(element) -- returns Boolean
SVGLocatable.enclosedBy(element) -- returns Boolean

SVGLocatable.enclosesElements() -- returns dom::NodeList
SVGLocatable.enclosedByElements(parentElement) -- returns dom::NodeList


On Wednesday, October 1, 2003, at 02:39  PM, Gavin Kistner wrote:
> 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
>
>
--
Gavin Kistner @ Refinery, Inc.
gavin@refinery.com
work: +1.303.444.1777
cell: +1.303.641.1521

Received on Monday, 6 October 2003 16:02:15 UTC