- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 12 Apr 2011 17:31:25 -0700
- To: robert@ocallahan.org
- Cc: Simon Fraser <smfr@me.com>, www-style list <www-style@w3.org>
Now, the mouse part of the discussion. Currently, there is one interoperable bit of location information returned by mouse events - the position relative to the viewport. Unfortunately, it's exposed via the unintuitive name of 'clientX' and 'clientY'. Some browsers expose other information - IE and Webkit expose offsetX/Y which is relative to the element itself, which is a very useful bit of information. It's not perfect, though - if you want to listen to mouse events on an ancestor (or on window) and still get coordinates relative to a chosen element (for example, if you're drawing into a canvas, and want to still track the mouse when it's outside the canvas), then you have to switch back to using clientX/Y and subtracting the element's own position. All told, there appear to be three pieces of information that we want to expose: 1. Mouse coordinates relative to the viewport. 2. Mouse coordinates relative to an element's layout box(es) 3. Mouse coordinates transformed into an element's own (transformed) coordinate space. #1 is necessary just in general, because "coordinates relative to the viewport" are the lingua franca of positioning. It makes it easy to do lots of things involving positioning things relative to the mouse, or reacting to the mouse position, or similar. #2 is necessary so you can easily do things like positioning an abspos element relative to the mouse (measure the mouse position relative to the abspos's containing block), or drawing into a canvas based on the mouse. #3 is necessary for the same as the above, in the presence of transforms. We might be able to combine #2 and #3 together; I'm not sure there are any significant use-cases that need #2 specifically. One that I can come up with is Positioned Layout - say you have a transformed container with an interesting element in it, and you want to position an abspos, rooted to that container (via position-root) but not contained within it, relative to the element in the container. That's very niche, though, so I dunno. Assuming that #2 and #3 can be combined, here's a possible solution in the same vein as my other suggestion: MouseEvent.getPoint(<relativeTo>, <part>) <relativeTo> is an element reference. <part> is defined the same as in the previous email, with values of 'margin', 'padding', 'content', 'inner', and 'scroll'. The return value is an object exposing x and y properties, where the values are relative to the top-left of the element, in the element's own coordinate system (that is, taking transforms into account. You can omit both arguments (just calling event.getPoint()) to get the coordinates relative to the viewport. ~TJ
Received on Wednesday, 13 April 2011 00:37:32 UTC