Tooltip

Page history last edited by Todd Parker 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

 

  • M2 Sticky tooltip - isn't this just a very lightweight dialog?
    • This tooltip allows for interaction within the tooltip by the end-user for things like forms, links and buttons.
    • Close [x] icon at top right corner allows the user to close the tooltip when clicked
    • Default settings:
      • Show on Click
      • Hide on "Blur" (User clicks elsewhere on the page)
    • Optional settings:
      • Open on mouseOver instead of onClick.
        • In this case, an extended mouseOver is used and does not close the tooltip immediately when the user mouses off the originating element.
      • Auto close when a user mouses off the tooltip after a specific time delay

 

  • 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 

 

 


 

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:

  • n/a

Events:

  • n/a

 


 

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 being discussed

 

Collision detection (implemeneted via Position) will change the resulting position of the tooltip. If the user specifies that he wants the tooltip on the top right, with the arrow placed accordingly, that has to be reintepreted after a collision. We need to figure out the API that lets the user specify the tooltip and arrow position in the first place, as well as influencing the collision result.

Currently the Position plugin doesn't provide any information about changes due to collision detection, so the Tooltip has to figure out itself where the element actually ended up at.

 

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

 

IE6 rendering of callout:

 


 

 

 

 

Comments (36)

profile picture

Almog Baku said

at 6:38 am on Apr 19, 2009

**** EDIT: THIS IS THE RIGHT LINK ****
http://craigsworks.com/projects/qtip/

profile picture

Todd Parker said

at 9:04 am on Apr 21, 2009

This jTip plugin is very impressive and looks like this would serve as a nice model for our feature set. The only difference I'd suggest for our tooltip is moving away from using canvas for corners (use corner-radius and our corner classes) and the triangle (use polygonal CSS) in order to use CSS framework styles and lighten up the weight of this plugin.

I wonder if there already is a plan to support framework styles to qTip to make this ThemeRoller ready.

profile picture

Todd Parker said

at 9:13 am on Apr 21, 2009

Jorn - I think this tooltip is really slick and pretty much all the functionality we need to cover. Adding a "sticky" tooltip that stays open and has a close button in the upper right would be a nice option. The collision detection generally works well, but in the map I see some going off the left edge of the page (probably will be fixed when we move to a positionTo plugin?).

Of course, the biggest changes would be styles. This should use the framework classes for the tooltip, defaulting to the ui-widget-content for the normal tooltip but you should be able to pass in a different class for the tooltip to change it's appearance (ui-state-highlight, ui-state-error or even ui-widget-header). This should also have the callout style arrow like jTip. This should probably be on as the default but could be turned off as an option. There are 2 potential callout arrow styles -- the one in jTip matches the border color with the arrow and leaves the content as a rectangle which looks cool. Filament cooked up a sample that used 2 overlapping polygonal arrows to make this look more like a proper callout with a dropshdow around it and this seems like a good default appearance: http://www.filamentgroup.com/lab/image_free_css_tooltip_pointers_a_use_for_polygonal_css/

profile picture

Andrew Powell said

at 2:40 pm on Apr 21, 2009

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.

profile picture

Todd Parker said

at 10:13 am on Apr 22, 2009

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.

profile picture

Andrew Powell said

at 12:17 pm on Apr 22, 2009

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.

profile picture

Byron McCollum said

at 6:44 pm on Apr 21, 2009

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

â—¢ â—£ â—¤ â—¥ â–² â–¶ â–¼ â—€

profile picture

Todd Parker said

at 10:18 am on Apr 22, 2009

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?

profile picture

Byron McCollum said

at 3:47 pm on Apr 22, 2009

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

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

profile picture

Igor said

at 10:56 pm on Apr 22, 2009

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.

profile picture

Byron McCollum said

at 12:23 pm on Apr 24, 2009

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.

profile picture

Andrew Powell said

at 12:18 pm on Apr 22, 2009

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

profile picture

Andrew Powell said

at 12:20 pm on Apr 22, 2009

profile picture

Eric said

at 8:38 am on Apr 22, 2009

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

profile picture

Eric said

at 5:38 pm on Apr 23, 2009

profile picture

Todd Parker said

at 6:07 pm on Apr 23, 2009

@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?

profile picture

Andrew Powell said

at 6:53 pm on Apr 23, 2009

(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 **.

profile picture

Todd Parker said

at 7:12 pm on Apr 23, 2009

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.

profile picture

Eric said

at 6:14 pm on Apr 24, 2009

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

profile picture

Todd Parker said

at 2:19 pm on Apr 30, 2009

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.

profile picture

Jörn Zaefferer said

at 5:37 am on Jul 11, 2009

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?

profile picture

Scott González said

at 7:55 am on Jul 11, 2009

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.

profile picture

Jörn Zaefferer said

at 2:23 am on May 20, 2009

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

profile picture

Todd Parker said

at 11:51 am on Jul 14, 2009

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.

profile picture

Craig Thompson said

at 9:21 pm on Sep 16, 2009

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.

profile picture

Craig Thompson said

at 11:53 am on Sep 17, 2009

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?

profile picture

Jörn Zaefferer said

at 11:20 am on Sep 29, 2009

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.

profile picture

Jörn Zaefferer said

at 1:28 pm on Sep 29, 2009

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

profile picture

Lars Rune Nøstdal said

at 4:32 am on Oct 4, 2009

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');

profile picture

Jörn Zaefferer said

at 11:48 am on Oct 4, 2009

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

profile picture

Matt Smith said

at 4:39 am on Nov 7, 2009

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.

profile picture

Matt Smith said

at 4:56 am on Nov 7, 2009

profile picture

Jörn Zaefferer said

at 5:05 am on Nov 7, 2009

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

profile picture

Matt Smith said

at 6:37 am on Nov 7, 2009

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.

profile picture

Matt Smith said

at 7:18 am on Nov 7, 2009

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.

profile picture

Matt Smith said

at 7:20 am on Nov 7, 2009

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?

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