- From: Doug Schepers <schepers@w3.org>
- Date: Thu, 19 Nov 2009 12:34:37 -0500
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- CC: www-svg <www-svg@w3.org>, Jeff Schiller <codedread@gmail.com>
Hi, Boris- You're right, these methods certainly need more attention and clarification. We'll talk about this today... thanks for your valuable feedback. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs Boris Zbarsky wrote (on 11/13/09 11:26 AM): > On 11/13/09 3:49 AM, Doug Schepers wrote: >> A) SVGRect1 {x:20, y:20, width:0, height:0} >> getIntersectionList( SVGRect1 ); >> >> This is essentially a point that will return everything that intersects >> that point, regardless of document order > > I would have actually expected this to return nothing, since all > intersections are empty (zero area)... > > If that's not what's intended, the spec needs to be _very_ clear on > this, and then all sorts of interesting issues are raised. For example, > does a rectangle with x=0,y=0,width=5,height=5 intersect a rectangle > with x=5,y=5,width=5,height=5? I posit the intuitive answer that most > people would want is "no". How is this different from the case above? > > For what it's worth, in Gecko rectangles in the css renderer are > effectively considered closed on top and left and open on bottom and > right; so a rectangle with x=0,y=0,width=5,height=5 is described by the > inequalities: 0 <= x < 5, 0 <= y < 5. Hence the two rectangles I > describe above do not in fact intersect, and any rectangle with width=0 > or height=0 is the empty set. > > I'm not sure what Gecko's svg implementation does in this regard, though > I suspect it's similar. > > -Boris >
Received on Thursday, 19 November 2009 17:34:47 UTC