Search and Top Navigation
#10739 closed bug (fixed)
Opened January 02, 2015 11:23AM UTC
Closed March 26, 2015 11:35AM UTC
Last modified March 26, 2015 11:40AM UTC
Tooltip: Does not display in foreground when used in an html5 <dialog> element
Reported by: | rden | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 1.12.0 |
Component: | ui.tooltip | Version: | 1.11.2 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
Tooltips does not display in the foreground when used in an Html5 <dialog> element opened with the .showModal() method.
The issue does not appear if the <dialog> is opened using the .show() method.
I don't know if this is an acceptable bug because <dialog> is still in draft mode (and only supported in a few browsers for now) but I think it will be widely used in the near future.
I will try to find a workaround for now. I think it would help if you could provide a way to specify where to append the tooltip container in the DOM (like the 'appendTo' option of the autocomplete widget). Thanks for your great work and happy new year ;-)
- Tested on: Chrome 39 / jQuery 2.1.3 / jQuery UI 1.11.2
- Reduced test case: http://jsfiddle.net/6uhhL1q9/
- Dialog specification: http://www.w3.org/html/wg/drafts/html/master/interactive-elements.html#the-dialog-element
Attachments (0)
Change History (8)
Changed January 02, 2015 11:26AM UTC by comment:1
Changed January 02, 2015 03:37PM UTC by comment:2
This is an interesting one. I verified that you can't make an element that resides outside of a
<dialog>appear on top of its overlay (
::backdrop). It's not possible to z-index trump it. I don't think it's unreasonable to create an
appendTooption for the tooltip widget, but I'll let other give their thoughts.
Nevertheless, this use case is trickier than just that. I wrote a hacky extension that appends tooltips to the
<dialog>element directly (http://jsfiddle.net/6uhhL1q9/3/), which works, but the positioning logic is screwed up. It seems that some the spec's “magical alignment” might be at odds with our position utility. Someone would have to dig deeper to get to the bottom of that problem.
Changed January 02, 2015 04:08PM UTC by comment:3
Yes, I came to the same conclusion with an element outside of the <dialog>
.
As a temporary workaround, I defined an open
callback to move and reposition the tooltip (http://jsfiddle.net/6uhhL1q9/4/). But if you have a better way please let me know.
Changed January 05, 2015 05:49PM UTC by comment:4
status: | new → open |
---|
We can use the appendTo logic from other widgets, even without introducing the appendTo
option, and then adjust that to find dialog
in addition to .ui-front
from DOM traversal. The only issue is that dialogs try to contain their content, so the width of the tooltip will adjust by appending it to the dialog. This is a bit awkward, but I guess that's what happens when entirely new CSS concepts are created.
Changed March 23, 2015 11:13PM UTC by comment:5
Changed March 26, 2015 11:35AM UTC by comment:6
resolution: | → fixed |
---|---|
status: | open → closed |
Tooltip: Follow the standard appendTo logic
Even though there's no reason to ever configure the parent element via an
appendTo
option, following the standard logic is useful for scrollable
elements and native dialogs.
Fixes #10739
Closes gh-1517
Changeset: 8cf98798a58afb7197bce0d6ca1c5b658ae04011
Changed March 26, 2015 11:35AM UTC by comment:7
All: Include native dialogs in appendTo logic (ui-front walking)
Ref #10739
Ref gh-1517
Changeset: dc6703756d388b1f49be0637473a8d55b5ce9270
Changed March 26, 2015 11:40AM UTC by comment:8
milestone: | none → 1.12.0 |
---|
Complete jsFiddle test case: http://jsfiddle.net/6uhhL1q9/1/