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: |
Description
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.
Also I believe this could be filed under Bug as well, seeing as the event.originalEvent.target
in this case is the target of the mouseover
event, while the event.target
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 event.target
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:2 Changed 10 years ago by
Owner: | set to Ult Combo |
---|---|
Status: | new → pending |
You'll need to provide a use case. The title does not say it all...
comment:3 Changed 10 years ago by
Status: | pending → new |
---|
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.
comment:4 Changed 10 years ago by
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 follow-up: 6 Changed 10 years ago by
Status: | new → open |
---|
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 Changed 10 years ago by
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 theclose
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
.
Basically, I would like to have this target exposed, either through the
event
object or as an event handler parameter - maybeui.element
?