#9239 open feature ()

Opened April 22, 2013 04:57AM UTC

Last modified April 29, 2013 05:19PM UTC

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.

Test case

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.

Attachments (0)

Change History (6)

Changed April 22, 2013 05:15AM UTC by Ult Combo comment:1

_comment0:	Basically, I would like to have this [https://github.com/jquery/jquery-ui/blob/master/ui/jquery.ui.tooltip.js#L140-L143 target] exposed. → 1366608667589574
_comment1:	Basically, I would like to have this [https://github.com/jquery/jquery-ui/blob/master/ui/jquery.ui.tooltip.js#L140-L143 target] exposed, either through the `event` object or as an event handler parameter. → 1366612264555996

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

Changed April 22, 2013 01:36PM UTC by scottgonzalez comment:2

owner:	→ Ult Combo
status:	new → pending

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

Changed April 22, 2013 03:36PM UTC by Ult Combo comment:3

_comment0:	Well, there should be many use-cases. My specific one was was performing some checks on the hovered element to display the tooltip only when the said element is overflowing horizontally, [http://stackoverflow.com/q/16138869/1331430 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. → 1366645270848898
_comment1:	Well, there should be many use-cases. My specific one was was performing some checks on the hovered element to display the tooltip only when the said element is overflowing horizontally, [http://stackoverflow.com/q/16138869/1331430 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: \ \ http://jsbin.com/uxilag/50/edit \ \ Though I'd like to have a documented method or parameter passed to the open handler which I can safely rely on. → 1366645349065729
_comment2:	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, [http://stackoverflow.com/q/16138869/1331430 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: \ \ http://jsbin.com/uxilag/50/edit \ \ Though I'd like to have a documented method or parameter passed to the open handler which I can safely rely on. → 1366645488347014
_comment3:	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, [http://stackoverflow.com/q/16138869/1331430 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: \ \ http://jsbin.com/uxilag/50/edit \ \ 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. → 1366645625327473
_comment4:	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, [http://stackoverflow.com/q/16138869/1331430 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: \ \ http://jsbin.com/uxilag/51/edit \ \ 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. → 1366645792028740
_comment5:	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, [http://stackoverflow.com/q/16138869/1331430 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: \ \ http://jsbin.com/uxilag/52/edit \ \ 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. → 1366645902566545
_comment6:	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, [http://stackoverflow.com/q/16138869/1331430 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: \ \ http://jsbin.com/uxilag/54/edit \ \ 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. → 1366646104017362
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.

Changed April 28, 2013 02:37AM UTC by tj.vantoll comment:4

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.

Changed April 29, 2013 04:17PM UTC by scottgonzalez comment:5

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.

Changed April 29, 2013 05:19PM UTC by tj.vantoll comment:6

Replying to [comment:5 scott.gonzalez]: