Opened 10 years ago

Last modified 10 years ago

#9239 open feature

Tooltip: Expose element which triggered the tooltip inside open/close handlers

Reported by: Ult Combo Owned by: Ult Combo
Priority: minor Milestone: none
Component: ui.tooltip Version: 1.10.2
Keywords: Cc:
Blocked by: Blocking:


Title says it all. There's currently no clean way (that I'm aware of) of getting a reference to the element which triggered the tooltip.

Test case

Also I believe this could be filed under Bug as well, seeing as the in this case is the target of the mouseover event, while the and the this reference inside the tooltipopen handler points to the document.

As this is a delegated event at its core, shouldn't document be accessible just through event.delegateTarget while this and would reference the element which actually triggered the delegated tooltipopen event?

Can we have these references fixed, or a new property added to the ui object parameter or have a new parameter being passed to the tooltipopen/tooltipclose event handlers?

I believe this would be really useful for many developers out there. Thanks.

Change History (6)

comment:1 Changed 10 years ago by Ult Combo

Basically, I would like to have this target exposed, either through the event object or as an event handler parameter - maybe ui.element?

Last edited 10 years ago by Ult Combo (previous) (diff)

comment:2 Changed 10 years ago by Scott González

Owner: set to Ult Combo
Status: newpending

You'll need to provide a use case. The title does not say it all...

comment:3 Changed 10 years ago by Ult Combo

Status: pendingnew

Well, there should be many use-cases. My specific one was performing some checks on the hovered element to display the tooltip only when the said element is overflowing horizontally, SO thread here.

I believe the correct way to implement such functionality would be providing an option such as a filter callback which is called as soon as a hovered/focused item triggers the tooltip, and its return value should be a boolean indicating whether the tooltip should be displayed. Though, this would most likely take a lot more of effort to implement, let alone depending on the implementation it'd mix jQuery UI tooltips with native title tooltips which would be unwanted.

Hence if I can cleanly get the reference to the hovered element inside an tooltipopen handler to perform some checks on element and call ui.tooltip.hide() depending on the condition should suffice - this way the native tooltip is not displayed and the live cycle of the UI tooltip is preserved, though it has display:none all along its live cycle.

Here's a test case with a relatively more clean way of doing the requested feature:

test case; better performance version

Though I'd like to have a documented method or parameter passed to the open handler which I can safely rely on.

Other use cases include checking element's data/properties before displaying the tooltip.

Last edited 10 years ago by Ult Combo (previous) (diff)

comment:4 Changed 10 years ago by tj.vantoll

I've implemented the exact same overflow use case described by @Ult Combo. I could also see use cases where you'd want to grab data-* attributes from the element before displaying the tooltip.

So +1 for exposing the element as a property of the ui object.

We could name it item to be consistent with the items option.

comment:5 Changed 10 years ago by Scott González

Status: newopen

If we're going to add this to the open event, we should consider whether or not to expose this in the close event as well.

comment:6 in reply to:  5 Changed 10 years ago by tj.vantoll

Replying to scott.gonzalez:

If we're going to add this to the open event, we should consider whether or not to expose this in the close event as well.

We probably should so that you could undo something that you did in open. For example, add a class to the element in open and remove it in close.

Note: See TracTickets for help on using tickets.