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

Making mouse events less painful to deal with in SVG

From: Jonathan Watt <jwatt@jwatt.org>
Date: Thu, 30 Apr 2009 03:38:38 +0200
Message-ID: <49F9011E.3030409@jwatt.org>
To: www-svg <www-svg@w3.org>

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.

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.


Received on Thursday, 30 April 2009 01:39:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:17 UTC