Re: [css3-2d-transforms] [css3-3d-transforms] MouseEvent coordinates after CSS3 transform?

On Sat, 23 Jul 2011 12:13:12 -0300, L. David Baron <dbaron@dbaron.org>  
wrote:

> I'd also like a similar API for converting coordinates from an
> event, since that's one of the most common use cases.
[...]
> # Probably we want the |this| on these methods to represent either the
> # origin (event or ref_element) or destination (element) coordinate
> # spaces, so they'd actually have one fewer parameter.  So in other
> # words, they could have syntax something like:
> #   ref_element.toCoordinates(element, ref_x, ref_y)
> #   event.toCoordinates(element)
> # or,
> #   element.coordinatesFrom(ref_element, ref_x, ref_y)
> #   element.coordinatesFrom(event)
> # although I think those are probably horrible names.

Very good idea of passing the event directly to this new (proposed) API.  
It simplifies the code when handling events.

I would also suggest that, in addition to standard DOM Element nodes, we  
should be able to use this API with 'document' and 'window' objects:

Passing 'document' would to convert coordinates to/from the document  
coordinates (equivalent to MouseEvent.clientX coordinate system, as far as  
I understand; and the same coordinates as 'position: absolute' inside the  
initial containing block)

Passing 'window' would convert to/from the viewport coordinates (the same  
used by 'position: fixed').



During the development of a little web app I am writing, I found the need  
for two variants of this proposed API:

1. Give me the coordinates so that I can add a new object "inside" the  
reference_element.
2. Give me the coordinates in "the same coordinate system" as  
reference_element.


Just to give you practical use-cases for such variants, I had an  
absolutely positioned DIV that I wanted to drag around (using the  
drag-and-drop API):

I used the first variant at the 'drop' handler in order to find where  
should be the new position of the dragged element. However, if I only used  
this, then the top-left corner of the element would be aligned at that  
position, which is not natural for the user.

If the user starts dragging the element by its center, then the "hot spot"  
where he started dragging must be aligned to drop position. For this  
purpose I used the second variant at the 'dragstart' handler, so I could  
find the the offset between the mouse dragstart location and the element  
position (and then I stored this offset and subtracted it at the 'drop'  
handler).

Note that the reference_element is different in these two use-cases: at  
the 'dragstart', the reference is the element being dragged; while at  
'drop', the reference is the container element that will receive the  
dragged object.



I could implement this easily in my App using only the standard properties  
already available in browsers and well defined at specifications. However,  
it would be a nightmare to do the same if I start transforming the  
elements using CSS (which is something I'd like to do).


-- 
Denilson Figueiredo de Sá
Rio de Janeiro - Brasil

Received on Saturday, 23 July 2011 16:21:43 UTC