You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TL;DR: I think hoverIntent's approach is much better than plain delays for opening popups because it triggers fewer "false positives".
Tooltipster's current behavior, if I'm not mistaken, is to open popups after a certain time their associated element has been hovered. This works well enough in many cases, but it triggers many "false positives" in others (i.e. the user was just moving the cursor around and didn't really want a popup to appear).
There are two examples where this is more noticeable. If we have one big "tooltipstered" element, it will more probably than not open a popup even if the mouse cursor is just passing through it because it "accumulates" enough time. Another case is when there are multiple (smaller) elements close together and the cursor is passing through them. Even if the user spends only some milliseconds hovering over each of them, time will eventually "accumulate" and a popup will open on the last one (again, even if it had been hovered over for only a few milliseconds). I was wrong.
For these reasons, I believe hoverIntent's approach is much better because it calculates acceleration rather than plain delaying before triggering events. This way, I can move the cursor (almost) as much as I want without popups being opened unintentionally. This is just an example of a better approach, but there might be others, like immediately resetting the timeout when the user leaves an element (but that still wouldn't solve the issue with large elements).
The text was updated successfully, but these errors were encountered:
Hi, thanks for the message. Yes, this is an interesting alternative. Although it will not be implemented directly in Tooltipster for the sake of simplicity, we could probably make a Tooltipster plugin (v4 supports plugins) to make it work with hoverIntent out of the box.
But you may be mistaken about the "multiple (smaller) elements close together", since each tooltip "timer" is independant from the others, they do not accumulate altogether.
louisameline
changed the title
A better way to detect that popups should be opened
Using hoverIntent to trigger hover tooltips
May 11, 2016
Yes, I was wrong about the "smaller elements" example. I made that assumption from a (rather silly) experience: Using this fiddle, I moved the cursor back and forth over the "board" of elements, which followed what I described. However, just by using a different motion it becomes obvious that my assumption wasn't true. I apologize for not simply looking at the code before saying that. Anyway, I hope I could help with the idea.
FYI I looked into it today and I found that hoverIntent leads to memory leaks since you can't unbind your listeners. I think I'll wait a little for them to improve before I have a Tooltipster plugin relying on them. I opened an issue with my suggestions, we'll see what happens.
TL;DR: I think hoverIntent's approach is much better than plain delays for opening popups because it triggers fewer "false positives".
Tooltipster's current behavior, if I'm not mistaken, is to open popups after a certain time their associated element has been hovered. This works well enough in many cases, but it triggers many "false positives" in others (i.e. the user was just moving the cursor around and didn't really want a popup to appear).
There are two examples where this is more noticeable. If we have one big "tooltipstered" element, it will more probably than not open a popup even if the mouse cursor is just passing through it because it "accumulates" enough time.
Another case is when there are multiple (smaller) elements close together and the cursor is passing through them. Even if the user spends only some milliseconds hovering over each of them, time will eventually "accumulate" and a popup will open on the last one (again, even if it had been hovered over for only a few milliseconds).I was wrong.For these reasons, I believe hoverIntent's approach is much better because it calculates acceleration rather than plain delaying before triggering events. This way, I can move the cursor (almost) as much as I want without popups being opened unintentionally. This is just an example of a better approach, but there might be others, like immediately resetting the timeout when the user leaves an element (but that still wouldn't solve the issue with large elements).
The text was updated successfully, but these errors were encountered: