return current pageX, pageY with the event

[usmonster]

It could be generally useful if the event passed to the handlers could also hold the current X & Y coordinates of the mouse at the time of firing. This could be added as part of the event.data, or more seamlessly (though potentially an unwanted side-effect for some) copied over the pageX/pageY of the returned event itself. This would make it much easier for those who want their handler to, for example, position something relative to the location of the pointer at the time of firing.

Thoughts? If I have time and there's interest, I can put an example implementation in a pull request.

[roydukkey]

You're saying this doesn't work from the handlerIn and handlerOut? http://api.jquery.com/event.pageX/

[usmonster]

Correct, @roydukkey. handlerIn and handlerOut get passed the same original event that was triggered at mouseenter/mouseleave time, whose unmodified pageX and pageY will be that of the pointer when it first entered the target. This makes it a bit more inconvenient for one who wants to, for example, implement a tooltip effect that shows up next to the mouse pointer.

Here's an example of the behavior, which is most visible when the target element has a large area:
http://jsfiddle.net/RGULk/6/

You'll notice that the tooltip is positioned based on the pointer position at the last interval check, not at its position then the handler is actually fired. This is not good for UX.

[usmonster]

Whoops! Wrong linked issue. (Meant # 12.) Ignore above commit reference.

[flesler]

+1 for this issue. Worked around this temporary by passing cX and cY on the apply:

69.   return cfg.over.apply(ob,[ev, {x:cX, y:cY}]);

[usmonster]

@flesler, your workaround is one of a few ways to do it, though I think the most appropriate solution would keep the interface as close to normal "hover" as possible, i.e. just return an event by itself. It would be easy to implement: just before the handler is triggered, simply copy the X/Y values of the last mousemove event over the X/Y properties of the original mouseenter event that would be subsequently passed to said handler.

The real issue, however, is that this would be a change that could break the way some folks might be using the plugin today. They might rely on the current behavior, even though it is counterintuitive, IMO -- if you really want something as similar as possible to normal hover behavior, you arguably want the coordinates on the passed event to match the actual position of the mouse pointer at handler-time.

I'm more than willing to put in a pull request to add this behavior (including nice bold text in the changelog :) if @briancherne is in agreement with my copy-coordinates approach. Perhaps it can be an option, but I think it's more correct and in line with the spirit of the plugin to have this become the default behavior.

[flesler]

I'm aware that this is not a good final solution. Tried copying the values to the event (pageX,pageY) and that breaks the behavior, after an over, more are triggered once you move.

[usmonster]

@briancherne :bump:

Any thoughts on the above discussion?

Also, @flesler, can you please elaborate on how/when copying the *X/*Y values to the passed event breaks behavior? I'm not sure I understand. Perhaps provide a reference implementation and/or jsfiddle?

[briancherne]

@usmonster - I'm in agreement with the copy-coordinates approach, as the default (and only) behavior. Just make sure to increment the version and note the (possible) backwards incompatibility for folks that were using the pageX/pageY of the original event. If someone complains we can consider adding a configuration option.

[usmonster]

While implementing this I realize the possibility that the most common use case may care about the current pointer coordinates only for the over handler and not for out. That said, I'm hesitating--should I still copy the current values onto both events (for consistency), or is it better to copy them only for the over handler?

Copying current coordinates to the event passed to out would still allow access to the originalEvent's coordinates, though this could arguably be a more surprising/less intuitive default behavior..

Anyone have a compelling use case to support either option?

[usmonster]

I keep going back and forth on consistency vs. intuition issue, and it's blocking the release...

Basically, I'd just like some/any feedback as to whether it makes more sense to leave the out handler event as-is (it has the pointer coordinates of the original mouseleave event), or if it's objectively better to mirror the new over behavior by giving it the coordinates that are "current" at the moment when the handler is called (i.e. after the timeout, if any is given). Note that the latter behavior would require additional mousemove tracking between the mouseleave and said timeout, though the major benefit would be to make both current and mouseleave-time coordinates (via event.originalEvent) available to the out handler.

Thoughts? @flesler, @roydukkey, @briancherne?