W3C home > Mailing lists > Public > www-style@w3.org > April 2011

Re: [cssom] Element size/positioning information

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 12 Apr 2011 17:31:25 -0700
Message-ID: <BANLkTikryuq_wh9Pi+9Wd9+75Ee-cp+EWw@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:39 GMT