Comments (14)
You're saying this doesn't work from the handlerIn and handlerOut? http://api.jquery.com/event.pageX/
from jquery-hoverintent.
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.
from jquery-hoverintent.
Whoops! Wrong linked issue. (Meant # 12.) Ignore above commit reference.
from jquery-hoverintent.
+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}]);
from jquery-hoverintent.
@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.
from jquery-hoverintent.
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.
from jquery-hoverintent.
@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?
from jquery-hoverintent.
@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.
from jquery-hoverintent.
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?
from jquery-hoverintent.
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?
from jquery-hoverintent.
In my opinion it makes sense to leave it the way it currently is, because out means, well when the mouse moves out. So my vote is to leave e.pageX
and e.pageY
alone.
It would be easy to add e.delayedPageX
and e.delayedPageY
. But, I'm not in favour of modifying the behaviour of jQuery.
Wouldn't it be fine to update the out
signature to include a parameter for things that are additional to jQuery? Something along these lines:
// out: Function( Event eventObject, Object delayedCoord )
$( "p" ).hoverIntent( function() { }, function( event, delayed ) {
delayed.pageX;
delayed.pageY;
});
from jquery-hoverintent.
Thanks for the rapid feedback, @roydukkey! I agree with the semantics of out, though the same reasoning could be applied to the over case. One can imagine valid use cases where someone might want to have access to the actual handler-time coordinates instead of (or in addition to) the event-time coordinates for both mouseenter/"over" and mouseleave/"out" cases. Applying the same kind of modification for both event/handler pairs would also preserve a kind of semantic and behavioral symmetry.
All that said, I may be leaning slightly toward leaving the mouseleave/out case alone, at least for this release, since the necessity of the change is currently less compelling than for the mouseenter/over case. Still, I'll leave the issue open a bit for other feedback until a decision is made.
As for the proposed alternatives, I doubt we'd add a delayedPageX
value to the event or change the API of the handler in any case, especially since the latter could arguably be a more disruptive change. thanks for the suggestions, though!
from jquery-hoverintent.
Right. I did overlook the over case, but do you mind elaborating on how you feel the latter could be disruptive? Though the handler would be applied as Function( Event eventObject, Object delayedCoord )
both parameters are still optional and do not present any new requirements in implementing hoverIntent. out: function() { }
and out: function( event ) { }
would still be acceptable without any issue.
from jquery-hoverintent.
No problem! To elaborate, the disruption I was talking about is more to the users of the plugin, since hoverIntent is meant to be a drop-in replacement for .hover
. If hoverIntent passed its own proprietary object to the handler--which can be any user-provided function--we have no guarantee that the function would behave the same. What if someone reuses the out
function elsewhere and it already has different behavior based on its arguments? This would break for them. I think most behavior changes like this should be done in a way that doesn't change the API/contract that says "we will only pass an Event to the callback, even if your callback can take more arguments." Hope that makes sense.
from jquery-hoverintent.
Related Issues (20)
- Improperly triggers mouseout when hovering a child inputs auto complete suggestion. HOT 9
- create gh-pages branch, change official site to github.io HOT 7
- Check over/out methods gracefully. HOT 5
- make new version HOT 1
- Namespaces, unbinding and the .on() syntax HOT 7
- Add an minified version HOT 1
- Late firing on mobiles HOT 7
- Timeout only applys to mouseout method and doesn't affect mouseenter HOT 4
- Is it work with dynamically added element? HOT 3
- cdnjs issue was opened HOT 1
- remove bower.json
- 1.8.1 on NPM is a mismatch? HOT 7
- Disabled button not firing "over" (in a very specific circumstance) HOT 2
- handlerOut not triggered when domElement is removed dynamically HOT 3
- Improperly triggers mouseout when hovering a child inputs auto complete suggestion. HOT 3
- Possible bug HOT 3
- Deprecated jQuery HOT 1
- how to import like/in es6 modules? HOT 1
- ES6 version
- Typescript types needed HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jquery-hoverintent.