W3C home > Mailing lists > Public > www-svg@w3.org > April 2009

Re: Making mouse events less painful to deal with in SVG

From: Doug Schepers <schepers@w3.org>
Date: Wed, 29 Apr 2009 23:38:50 -0400
Message-ID: <49F91D4A.3080005@w3.org>
To: Jonathan Watt <jwatt@jwatt.org>
CC: www-svg <www-svg@w3.org>
Hi, Jonathan-

Jonathan Watt wrote (on 4/29/09 9:38 PM):
>
> I've been thinking about the problem of mouse event coordinates (clientX/Y and
> screenX/Y) being pretty useless in SVG.
>
> The problem is of course that you generally want to know where the mouse event
> occurred relative to the userspace established by some element. As things stand,
> to get that information authors generally need to get the transform to the
> client area using getScreenCTM, invert that transform matrix, create an SVGPoint
> form clientX/Y, then transform that point using their inverted matrix. Not
> surprisingly this is far from obvious to most authors, and people get it wrong
> since they think they need to use screenX/Y to match getScreenCTM, or they don't
> invert the matrix, and further, zooming screws up the transform anyway so that
> things won't work when the page is zoomed.

Yes, indeed, jumping through flaming hoops like this is only fun at the 
circus.

We've talked about this issue before, and I raised an issue on it a 
while back (ISSUE-2182):
  http://www.w3.org/Graphics/SVG/WG/track/issues/2182


> I'd like to propose that a clean and easy way to solve this problem would be to
> extend MouseEvent with a getPointRelativeTo method. Something like:
>
>    Point getPointRelativeTo(element):
>      Returns the location of the mouse event in the coordinate system
>      established by 'element'.
>
> That's far from spec quality text applicable to SVG and HTML etc, but you get
> the idea, and I'm just looking for feedback on the idea at the moment.
>
> One question is, should the point returned be in the coordinate system
> established *by* the element, or in the coordinate system established by the
> element's parent. I think probably the former. That way it's always possible for
> the script to pass in element.parentNode, but if we did it the latter way there
> may be no child (yet) that can be passed in.
>
> I think it would make sense that passing in null would get the coordinates in
> the userspace established by the nearest outer<svg>, or perhaps just the
> nearest<svg>. Not sure about HTML.
>
> Thoughts?

I think it might be useful to return an object that contains more than 
just the coordinates... there are times you might wish to get the CTM 
and such, for more complex operations.  But I'd be happy if we had 
anything like this at all.  The current way to get a simple point, 
especially when you are zoomed in, transformed, or viewBoxed, is insane.

I think that solving this for the author will lead to making clever apps 
an order of magnitude easier.  Thanks for bringing this to the fore. 
Are you available to talk about it at the next telcon?

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
Received on Thursday, 30 April 2009 03:39:01 GMT

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