Tooltip

Page history last edited by Jörn Zaefferer 1 mo ago

type: widget

release: 1.8+

status: in development

documentation: n/a

demo: n/a

1 - Description:

A tooltip is a small overlay that sits over the main page that can be used to provide content or functionality that does not need to be always visible. Tooltips usually look like a small box or callout and can be trigged by a wide range of events. All tooltips should employ collision detection and iframe protection via the Position utility.

General
- All tooltips should be automatically protected by the stackfix plugin to avoid z-index issues
- The tooltip body should automatically expand to the width and height of the content
  - Maximum width option may need to be set in the CSS to keep tooltips from getting incredibly wide, you want it to wrap at some reasonable width (200-400px)
    - This could be a problem in IE6 as there is no max-width support. CSS Expressions as an alternative?
  - Maximum height option (scrollbars should appear if content height exceeds tooltip height)

Content
- The default browser tooltip is always suppressed.
- If nothing is specified, the tooltip will grab the title attribute from the parent and display the title content unformatted.
- The content can be a string, including HTML markup, that will replace the title attribute
- The content can be a function that either returns the HTML markup to display, or uses the provided callback to get asynchronous content (eg. via Ajax)

M1 Simple tooltip
- This tooltip is used strictly for non-interactive content such as descriptions and text strings which cannot be directly interacted with by the end-user.
- Default settings:
  - Show on mouseenter, delayed by 150ms (configurable, could use hoverintent for more intelligent behaviour)
  - Hide on mouseleave

Animations
- Animations for the show and hide events should be optional to allow the tooltip to use any of the standard jQuery UI animated transition effects.
- Defaults:
  - Show: fade effect
  - Hide: fade effect

Positioning
- Relative to the cursor position
  - Static position: position tooltip based on position of cursor when called, no not re-position tooltip unless closed and re-opened (default)
  - Follow cursor position: constantly re-position tooltip as the cursor moves
- Relative to the parent
  - Can use any of the position placements: ex. left aligned and above parent; at the far right end of parent, above and to the right

Visual styles
- The tooltip should be completely compatible with the CSS framework and Themeroller, including the connector graphic ()
- Any custom class name including other framework container classes should be an optional parameter
  - widget-header, widget-content, state-default, state-hover, state-active, state-highlight, state-error can be passed in as an option so the tooltip can have different, themed styles
- The option to add in the shadow class (when complete) would be a good option

Callout connector (Tip)
- Created using polygonal CSS (http://www.filamentgroup.com/lab/image_free_css_tooltip_pointers_a_use_for_polygonal_css/) or Canvas/VML implementation. Or even a combination of both.
- By default, it should have the ui-widget-content class
- No callout connector: simple rectangular tooltip
- Callout connector triangle: In two variants, filled and unfilled connectors
  - For any of these styles, the connector (if present) can appear in any of the standard 12 positions around the perimeter of the tooltip body:
    - Top edge, left aligned
    - Top edge, center aligned
    - Top edge, right aligned
    - Left edge, top aligned
    - Left edge, middle aligned
    - Left edge, bottom aligned
    - Right edge, top aligned
    - Right edge, middle aligned
    - Right edge, bottom aligned
    - Bottom edge, left aligned
    - Bottom edge, center aligned
    - Bottom edge, right aligned
- A labs experiment for more accutare positioning: http://jquery-ui.googlecode.com/svn/branches/labs/tooltip-callout/index.html

Accessibility
- The tooltip must be fully accessible (ARIA) and should provide update announcements to screenreaders to ensure that the tooltip content is read correctly when activated

Exisiting Plugins

2 - Visual Design:

3 - Functional Specifications/Requirements:

Options:

content (String, Function, default: functions that returns the title attribute)
- The content of the tooltip, as HTML
- Can be a string to display
- Or a function that will either
  - return the content to display
  - call another callback (passed as the first argument) with the content to display, to enable asynchronous operations
- This is the right place to format the title by adding elements (with extra classes) or any other changes
position (Options, default: { my: "left top", at: "left bottom", offset: "15 -12" })
- Configuration for the Position plugin, of-option excluded (always configured by widget)
tooltipClass (String, default: "ui-widget-content")
- additional classes to put on the tooltip
- can be CSS framework classes like uwidget-header, widget-content, state-default, state-hover, state-active, state-highlight, state-error

Methods:

Events:

show
- triggered whenever the tooltip is shown
- gets an ui object with a target-property, which can differ from the actual element when using event delegation

4 - Markup & Style:

4.1 Initial markup examples

(Pre-enhanced HTML markup structure that will be transformed into the final widget. There may be multiple possible HTML markup options per widget: for example, for a slider, radiobuttons, inputs or selects could all be used. )

4.2 Recommended transformed HTML markup

(The HTML markup structure and classes that will be used by the scripts in the enhanced version)

4.3 Accessibility recommendation

(Detailed recommendations for ARIA, HTML markup, CSS and javascript that will contribute to universal access and full section 508 accessibility for screen readers, mobile devices and any other devices)

4.4 CSS & Theme

(Description of the CSS classes to be used for all states, how custom theming and Themeroller support will work.)

5 - Latest version of plugin:

http://jquery-ui.googlecode.com/svn/branches/dev/tests/visual/tooltip/default.html

6 - Open issues

Ajax tooltip: Cancel the request or at least ignore the response if it happens after close.

Event handling: mouseeenter/leave doesn't bubble (not even with 1.4, there only in combination with live)

Cursor flickering in IE6

Comments (Show all 43)

That is a pretty wicked technique. My only erks about that are IE6 and 7. Sadly, they're both still relevant.

In IE7 the triangles just look lowsy (no way to sugar coat that nicely); very jagged.
I read through the comments and saw that IE6 would require a solid border color.

Most of our plugins degrade the rounded corners very nicely to a regular old rect. This doesnt take away from the plugin at all ascetically. The failure of IE to (what looks like) anti-alias in this regard results in a less than pleasing visual result. Unfortunately I don't have any suggestions other than using images *shudder* but I can attest that the visual quality would be a deal breaker for this plugin on the enterprise app I work on.

The issue we need to deal with is themes. If we go with images for these for IE, it is going to add a ton of overhead to ThemeRoller. I guess if the polygonal approach isn't good enough for IE, why not just show a rectangular tooltip without the triangle? It fits with the degrade to rectangle approach elsewhere.

Yeah will be an issue. However, degrading to a point where a very usable (and expected) visual element is missing isn't really the best route either. I still dig the use of canvas (and whatever the hackey, but functional IE equiv. is) and I think I'll spend some time looking into the possibility of either calculating a fill color, or css in some fashion.

This may be a little hacky, but why not use unicode geometric shapes for the leader?

◢ ◣ ◤ ◥ ▲ ▶ ▼ ◀

This seems like another cool approach. I wonder how well this is supported across browsers, OSs and and character sets. Anyone want to test this out?

Here is a quick demo...hope it sparks some creativity.

http://bgmccollum.com/jqueryui/tooltip/

An option you think?
Seems to me not just "little hacky" but all at once "pretty tricky": triangle positioning failed on Opera 9.64, FF 3.0.7, IE 6.

Sorry, I didn't get a change to fully test it. It worked in Safari and FF on my Mac. I think the biggest pitfall of the technique is that we would be working against all the disparate text rendering engines / font sets across all the browsers / OSes.

Thats cool :) I've never run across this before.

For reference;
http://www.alanwood.net/unicode/geometric_shapes.html < would be ideal for cross platform/browser tests.
http://en.wikipedia.org/wiki/Unicode_Geometric_Shapes

wouldn't it be better creating triangles using borders? that way it'll be total css jquery and html

I have made a demo:
http://shedokan.110mb.com/jquery/tooltip.html

@Eric This is very cool. So this uses the polygonal CSS technique for all the arrows? It's nice to see all the various arrow types all worked out in code as a proof of concept. I personally think this is a safer way to go compared to the unicode because I don't how we'd be able to use a character (text) style to color this to match the theme and I'm not sure where this works reliably.

Since this needs to be ThemeRoller-ready, we need to approach the coloring of these a bit differently so we can simply apply the framework classes to the arrow and shadow divs so the theme colors cascade through without needing to be hard-coded, like the example we did here:
http://www.filamentgroup.com/lab/image_free_css_tooltip_pointers_a_use_for_polygonal_css/

It would be cool if this was coded in ems instead of pixels (if possible) so the tooltips would scale gracefully (see example above). On FF3/Mac, I'm seeing the text wrap to 2 lines and break outside the boxes for 3 of the examples on the right. Did you test this out in all the standard UI browsers to make sure it all checks out?

(reference: http://www.alanwood.net/unicode/geometric_shapes.html) Open up Firebug and change the font color. Theyre text characters, so the color is simply a function of setting color: #;

I'd like to reiterate that using borders for the triangle generation looks pretty bad (jaggies) on IE with any dark border color. Using unicode characters can be done using pure html + css as well and looks a whole heck of a lot better ** cross browser **.

Hi Andrew - I think this is a potentially cool approach and there are some really sweet characters in that set that I never knew about. Since I'm not familiar with the specifics of the character set across devices, I'm just wondering f you had a chance to to some testing.

This page says "The characters that appear in the first column of the following table depend on the browser that you are using, the fonts installed on your computer, and the browser options you have chosen that determine the fonts used to display particular character sets, encodings or languages."

So my questions are:
- Do these triangle characters look correct (and consistent) in all our supported browsers and platforms?
- What happens when this fails and character isn't available? Do you see a rectangle or some other odd character?
If this checks out, I'd be interested in seeing a static proof of concept for the various tooltips like Eric just did with the polygonal css. If it's flexibly sized and themable, I'm very interested.

Igor said Byron's simple example unicode triangle positioning example above failed on Opera 9.64, FF 3.0.7, IE 6 so it sounds like we need someone to build a solid prototype to thoroughly test since this is all new to us. It's very promising though.

I have changed it to be themeroller ready, and tried using em's.

I've updated the description and created new wireframes for the tooltip types and connector arrow positions. After designing these, we're recommending that we just have two visual options for the tooltip: basic rectangle and arrow connectors (in all 12 possible positions). Please review these two sections and provide feedback and ideas because this plugin is getting close to development.

The close-icons on the sticky tooltip indicate that they have to be clicked to close a sticky tooltip. Considering their tiny size, that really isn't a good idea.

Also, I wonder how sticky tooltips and dialogs (or modals, for that matter) are related. Isn't a sticky tooltip kind of a modal or dialog? What are the differences?

Richard and I talked about this at jsconf. I don't remember if we had a specific answer, but our thought was that the initial version of tooltip just wouldn't support sticky tooltips.

I've updated my formtooltip plugin as a reference: http://jqueryjs.googlecode.com/svn/trunk/plugins/tooltip/demo/formtooltip.html
Notable about that: It uses event delegation on the form, so no need to rebind any events. The rounded corners and pointy-thingy are all in a single CSS sprite, png-8, even works in IE6. The fading is heavily tuned and should break even when tabbing wildly around fields.

There there is also the CSS polygon demo, dunno how relevant this still is: http://jqueryjs.googlecode.com/svn/trunk/plugins/tooltip/demo/fg-poly-demo/index.html

At the very least, we need to keep this themeable so a PNG background image won't cut it. In the most basic form, the tooltip is just a div with a framework class on it (which class should be configurable via options, maybe default to ui-widget-content or ui-widget-highlight).

I think we should still try to get the arrow into the tooltip, especially since Scott has all the classes worked out. It seems like the rules could be pretty simple since the arrow is calculated off the position to the parent. So if a tooltip opens from the right side, top (RT) of the parent, we would place the arrow in the lower left corner of the tooltip to visually connect them. It might just be the opposite of the parent positioning T > B and L > R unless collision detection happens then that direction wouldn't be flipped. Does position to have a way to communicating if a direction was flipped or fitted for collision detection? That seems like essential info for a plugin to be able to tap into.

I'm currently working on converting my qTip plugin (http://craigsworks.com/projects/qtip) into a standardised UI widget. I'm having a lot of success in the new revisions of my code. Currently I've got Themeroller support replacing my old styling system, as well as decent ARIA support as far as I can understand the specification.

99% of the specification above is present in the conversion. You can checkout the code so far here on the launchpad branch: http://bazaar.launchpad.net/~craig.craigsworks/qtip/trunk/files
Feel free to play around with it and give some feedback.

Also, at the moment the tooltip is using the Position plugin as mentioned in the article, but it was somewhat limited for the needs of the tooltip. For instance, the lack of collision states sent to the "by" callback, as well as support for detecting correct AREA elements height/width. Therefore, I've modified the code of the plugin and inserted it directly into the jquery.qtip.js script for now, until I can submit the changes I've made for review.

I believe there's two vital questions that needs some discussion for the specification in this case:

1. Will tooltips be pre-rendered? And if so, how much will this impact page load times? My experience from qTip shows that pre-rendering should be a last resort to maintain load times.
2. Event delegation or event handling? Delegation is the obvious choice, but working with event handling allows us the ability to use non-bubbling events such as focus and blur (I heard theres working being done in the jQuery core to make these bubble also?

When positioning relative to the element, a mouseout on the element that is also a mouseover of the tooltip should NOT hide the tooltip, only hide it when the mouse is outside both elements. Apart from enabling to copy tooltip content, it makes the sticky tooltip even more useless.

Reference for that behaviour: http://flowplayer.org/tools/demos/tooltip/

Hi,
Without having thought about this much, the tooltip seems to work better when if(!target){ target = this.element; } is inserted at line 42 in jquery.ui.tooltip.js. This might not be correct (it seems a bit weird), but this worked well when forcing the tooltip to show up early.by doing $(..).tooltip('show');

That sounds like a reasonable idea. I'll add that example to the tests.

I'm running into an issue with the tooltip widget when applied to a button widget. when the mouse goes over the button-icon element and the button-text element the tooltip disappears. Presumably because detection shows that the mouse is now over a different element.

here is a visual test http://clients.800px.com/ui-formvalidation/buttontooltip.html

Just commited a fix for button to properly set the the title-attribute. Give that a try: http://jquery-ui.googlecode.com/svn/branches/dev/tests/visual/button/default.html

I don't think it's an issue with button in my testing it's to do with child elements within the element that has had tooltip applied to it. in the case of a button widget at present you would have apply the tooltip to both icons and the text span so that you get a ui toolip. if you look at my test page you will see the last item on the page is a div within a div. the title attribute is passed through but the tooltip element is not.

this may actual fact be an issue with the detection used by the tooltip it needs to pass it's function down the child tree in some instances and button is a good example of where this would be expected.

The same issue would be raised by any sliding door elements in a html page if the tooltip is only applied to the outer sliding door.

on line 24 of jquery.ui.tooltip.js you have used two bind methods to bind the show and hide to both focus and mouse events. if you use the jQuery hover method along with a binding just for focus you will fix this issue.

I realize that using hover will break the system of ui dot events so potentially the hover method of the jQuery object needs to be modified by ui-core?

I just wanted to say that the tooltip widget has made the formvalidation utility I'm working on ten times easier. http://clients.800px.com/ui-formvalidation/

I have just discovered something with the tooltip widget that I don't think is right. When you disable the tooltip which I do in the formvalidation you add the disabled class names to the widget element. I know this is core to the widget factory but is this correct in the case of the tooltip?

No, that doesn't make sense. In this case the tooltip itself should be disabled (no need to add any classes there) and thats it. I'll update that.

Tooltip now overrides both enable and disable methods to only set the disabled-option. When tooltip is disabled, the element will behave like there is no Tooltip widget at all, which probably isn't the desired behaviour either, that is, the native tooltip is displayed on hover. Any opinions on that?

Hi, all.
Can you please look to new tooltip widget.
Unfortunately, now it doesn't support sticky and you can't disable connector (it always is visible).
It has awesome content system, it supports not only static title and callback function also you can use template string with fill it by local or remote JSON parameters.
You can see demo in this page http://jquery-tooltip.googlecode.com/svn/trunk/demos/demo.html
For more information about this widget, methods, event visit description page http://iggant.blogspot.com/2009/11/jquery-tooltip-widget-jtooltip.html
Please feel free to comment it or may be improve.

I tried to integrate this tooltip into my accessible form validation widget and must confess this plugin breaks ui.position by using hide().
See http://www.felixnagel.com/fileadmin/downloads/Formular.zip for a demo. Just try to check a one selectbox, then go to tooltips.js and comment hide() out. Now it works.

This _init method works for me. _init: function() {
var self = this;
this.tooltip = $("<div></div>")
.attr("id", "ui-tooltip-" + increments++)
.attr("role", "tooltip")
.attr("aria-hidden", "true")
.addClass("ui-tooltip ui-widget ui-corner-all")
.addClass(this.options.tooltipClass)
.appendTo(document.body);
this.opacity = this.tooltip.css("opacity");
this.tooltip.css("opacity", 0);
this.tooltipContent = $("<div></div>")
.addClass("ui-tooltip-content")
.appendTo(this.tooltip);
if (!this.options.noHover)
this.element
.bind("focus.tooltip mouseover.tooltip", function(event) {
self.show($(event.target));
})
.bind("blur.tooltip mouseout.tooltip", function(event) {
self.close();
});
},

You don't have permission to comment on this page.

Anonymous Create an account or Log in

Tooltip

1 - Description:

2 - Visual Design:

3 - Functional Specifications/Requirements:

4 - Markup & Style:

4.1 Initial markup examples

4.2 Recommended transformed HTML markup

4.3 Accessibility recommendation

4.4 CSS & Theme

5 - Latest version of plugin:

6 - Open issues

Tooltip

Page Tools

Insert links

Comments (Show all 43)

Andrew Powell said

Todd Parker said

Andrew Powell said

Byron McCollum said

Todd Parker said

Byron McCollum said

Igor said

Byron McCollum said

Andrew Powell said

Andrew Powell said

Eric said

Eric said

Todd Parker said

Andrew Powell said

Todd Parker said

Eric said

Todd Parker said

Jörn Zaefferer said

Scott González said

Jörn Zaefferer said

Todd Parker said

Craig Thompson said

Craig Thompson said

Jörn Zaefferer said

Jörn Zaefferer said

Lars Rune Nøstdal said

Jörn Zaefferer said

Matt Smith said

Matt Smith said

Jörn Zaefferer said

Matt Smith said

Matt Smith said

Matt Smith said

Matt Smith said

Matt Smith said

Jörn Zaefferer said

Jörn Zaefferer said

iggant said

fnagel said

fnagel said

Join this workspace

Navigator

SideBar

Recent Activity