W3C home > Mailing lists > Public > public-svg-wg@w3.org > October to December 2009

Re: intersection test review, struct-dom-11-f.svg

From: Erik Dahlstrom <ed@opera.com>
Date: Mon, 14 Dec 2009 13:14:23 +0100
To: "Cameron McCormack" <cam@mcc.id.au>
Cc: public-svg-wg@w3.org
Message-ID: <op.u4xf97ccgeuyw5@localhost>
On Mon, 14 Dec 2009 10:40:59 +0100, Cameron McCormack <cam@mcc.id.au>  

> Hi Erik.
> Erik Dahlstrom:
>> I've tested Batik 1.7 and Opera 10.10, and it seems like "initial
>> coordinate system" from the definitions of the above methods may
>> have been interpreted differently. Opera expects the rectangle that
>> is passed in to be in initial viewport coordinates[1], so to pass
>> the test the coordinates that are given in the test (which seem to
>> be in user units) need to be transformed first. The test works fine
>> if and only if the userspace coordinate system matches the initial
>> viewport coordinate system, or in other words when the computed size
>> of the svg image matches the viewBox. If loading the svg file
>> separately in Opera it fails because the two coordinate spaces
>> usually don't match.
> Do you have an opinion on whether the initial viewport coordinate system
> or the initial user coordinate system makes more sense?  IMO, the latter
> does, since that’s the coordinate system that graphics elements are in.

Both make some sort of sense. If you consider mouse events then you can  
take the MouseEvent.clientX/Y[4] directly as the (x,y) of the rect  
argument to the getIntersectionList/checkIntersection method. The good  
thing about keeping it in initial viewport coordinates is that it's  
axis-aligned and "untransformed", closer to the pixel buffer and closer to  
the normal mouse input for hit testing.

>> Batik seems to not honor the 'pointer-events' property when
>> considering which elements to return, while Opera does.
> That is a bug, I suppose.  (Although it would be good for the spec to
> state explicitly what honouring means, here.)

Yes, I agree about replacing "honouring" with something better, though I  
think the intent is still rather clear. Do you have any suggestions for a  

Here's my rewording suggestion:
   Returns the list of graphics elements whose rendered content intersects  
the supplied rectangle.
   A graphics element is to be considered intersected if only if the same  
graphics element can be a [target
   of pointer events][1] (, as defined in 'pointer-events'[1] processing).

>> The test has a <g> element that has visibility="hidden" and it expects
>> the elements inside to be intersected. This is not the case unless e.g
>> pointer-events="painted" is specified.
> Ah.
>> Opera expects the elements to be within the viewport, while Batik
>> has no problems with elements outside the viewport. Anyway, moving
>> the elements in the test a bit and adding pointer-events="painted"
>> makes it pass in both viewers (as long as the testframe dimensions
>> matches the viewBox).
> OK.  I don’t think there is anything that implies that elements outside
> the viewport are to be excluded, except perhaps the mention of
> pointer-events (which sort of ties the behaviour of these methods to the
> visibility of the elements).

Right, I suspect that Opera's behaviour here stems from implementing these  
methods quite close to how mouse event intersections are handled (no mouse  
events can occur outside the viewport).

>> To make the test more robust the userspace coordinates
>> used in the 'rect' parameter need to be transformed to the
>> initial viewport coordinate system before passing it to
>> checkIntersection/getIntersectionList.
> I’m OK with the test being modified to avoid these issues for now, but I
> think that the spec should be clarified wrt to the coordinate system
> being used (as well as for the viewport clipping issue).

OK. I've reread the definition for "initial coordinate system"[2], and  
also section 7.4 "Coordinate system transformations"[3]. I think it's  
rather clear that if you have a 'viewBox' attribute that establishes a new  
user coordinate system different from the "initial (viewport/user)  
coordinate system". I'm not exactly sure where in the spec that should be  
clarified though (probably in coordinate systems somewhere if so), but I  
think that linking from the method definitions to section 7.3 "The initial  
coordinate system" would be good in any case.


p.s. Hello trackbot, this relates to ACTION-2695

[1] http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty
[2] http://www.w3.org/TR/SVG11/coords.html#InitialCoordinateSystem
[3] http://www.w3.org/TR/SVG11/coords.html#EstablishingANewUserSpace
[4] http://www.w3.org/TR/DOM-Level-3-Events/#events-mouseevents

Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Monday, 14 December 2009 12:13:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:42 UTC