Javascript, HTML content in tooltips.

You are probably asking yourself, "Self, why do we need yet ANOTHER Javascript tooltip?"

Good question, only you know the answer to that for your applications but for mine, none of the ones available fit what I needed so I came up with this.

It's more of a mini-library...

A tooltip library, of sorts

Although this code can easily be used as is and stand-alone by being included directly into HTML tags through the use of inline event handlers, its greatest flexibility and usefulness comes in during its use as a tooltip library used by scripts that extend it's functionality in different ways for different applications as well as providing a means to keep the Javascript out of the HTML.

Right before your very eyes!...

Examples in use

You may have noticed the external site link preview popups visible when you mouse-over just about any external link on this site.

In addition the HTML title attribute replacement technique can easily be viewed by stopping your mouse over one of the site configuration images in the upper right corner of the page header or stopping your mouse over one of the main menu elements to the left. Or, simply by mousing over the word "title" in the just previous sentence saving you the trouble of having to scroll up, which you probably already have done. That's site usability for you.

Both uses may seem to be exactly the same and although they do use the same core script, which this project describes and documents, their functioning is totally different.

You will hopefully notice that the site preview tooltip is visible the entire time during a mouse-over while the HTML title attribute replacement not only display only after the mouse has stopped moving, as it would for a normal browser supplied title attribute display but also, moving the mouse within the target element but not leaving it and then stopping again, causes the tooltip to display again, as it would again for a browser supplied HTML title attribute display.

Those are just two of the examples I have of this code in use on this site currently but don't be surprised if there are more in the future.

Prior art...

"Tooltips" implemented by others

The following is a list of existing implementations that are popular enough to rate in the top search engine results on Google. (In no particular order)

I'd like to note here that of the ones listed, my favorites are the first and second with my implementation having many similarities with the second although at the same time, many differences as well.

Bennies?...

Javascript tooltip Features

The following list is not meant to indicate that all the flavors of Javascript tooltips currently in existance have all these problems but it was a combination of all these problems that lead me to create this version.

  • This version works. Some ranked high in Google seem to do nothing but sit there spinning Javascript errors endlessly. Also, in all the top browsers currently available, there were no problems.
  • The tooltips documented here don't use browser detects but instead, object and function support detection.
  • These don't run off the edge of the screen but intelligently position themselves based on the target position relative to viewport edges.
  • Function and style are separated into Javascript and CSS files.
  • These don't try to do too much although they do a lot. In other words, they have "basic" display and positioning functionality but other than primitive usage within HTML tags as event handlers, they leave the job of providing applications to extension scripts which are used to determine when, where and how the tooltips are actually used.
  • Their basic display is much more advanced than any of the many Javascript tooltip implementations I have seen especially with the top/bottom flipping left/right sliding pointer whose position and orientation is determined by the relative position of the tooltip with respect to the view port itself.
Who needs it?...

Information compression

In many applications, the amount of information available is much greater than one's ability to take everything in at one time. As content density goes up so does "skimming" and comprehension and retention accordingly goes down.

Also, there is no such thing as a homogeneous audience and different users will be interested in different things but forcing all to sift through everything or the opposite, limiting information for the "average" user ends up being just like the saying, "Something that tries to do everything usually ends up doing nothing."

Providing a layered approach where the immediately visible content is more general while providing quick and easy access to more detailed information is a useful technique to satisfying more consumers of the information you provide.

Although a techno-blog like site such as this doesn't really provide opportunities to show off the usefulness of what can be accomplished, sites such as e-commerce, product listing or any other sites where there can never be too much information available that one can use to influence a selection or purchse are much better targets.

If it ain't broke, ,...

Why Javascript tooltips are useful

Although I will go into this more in subsequent articles that expand upon this "library", the tooltips that everyone have become familiar with since even some of the original GUI based systems have existed have three serious drawbacks.

Most importantly, if one is visually impaired to the extent that larger text size is required, how does one go about increasing the font size of the common application dependant/provided (ADP) tooltips? Answer, you don't.

ADP tooltips also suffer from being unable to effect various parameters that control their functioning such as delay to display, delay to hide, font color, background color, contrast etc.

You can put anything you want into an ADP tooltip just so long as it is text, simple text, short text. Even if the information you want to display is purely text, one can run out of realestate pretty quickly.

A number of applications, MySQL Administrator being my favorite tool to use for administrating databases as well as my favorite tool to hate exactly for this reason, have a nasty habit of providing tooltips to display content that is actually too long to display in the page by using tooltips that are equally too long to actually fit in the page. Anyone else see a problem with that picture?

You got you got you got what I need!...

Requirements

The following is a list of functions and features I felt needed to improve upon the proverbial revolving thingy :

  • Self positioning so that the risk of portions of the information displayed being positioned outside the view-port is reduced as much as possible.
  • Providing the ability to apply style information separately from the Javascript processing.
  • Don't rely on browser detects to determine display and positioning parameters.
  • Automatically resize yet never adopt a size putting information out of reach outside the viewport.
  • Continue with the pointer image concept present in the Cool DHTML Tooltip II tooltip implementation but carry it forward to support the pointer being present whether the tooltip is displayed above or below the mouse cursor and also, slide along the tooltip left to right when forced to do so if the tooltip should come in contact with the right edge of the view-port.
  • Provide the ability to scale any text present in the tool-tip along with or separately from the page content itself.
  • Support the inclusion of any HTML element within the display of the tool-tip
  • To the extent possible, limited only by browser peculiarities of Internet Explorer, support the fading in of tooltips to prevent them from becoming overly distractive and only augmenting the content present in the page as opposed to getting in the way of it.
  • Interfere as little as possible with other scripted effects that one might apply.
  • Work equally well in all HTML 4.0 compatible browsers.

Note that although some of the existing implementations come close to matching many of these functions and features, with the Cool DHTML Tooltip II coming the closest, none of them match them all.

How will this work?...

Tooltip construction and display

Initial tooltip setup

Although the core construction of a given tooltip is relatively simple employing only 3 elements, a div as a container and a couple of images for pointers, the number of times a tooltip of any type might be used on a given page might be significant.

And, as the chance of causing memory leaks is reduced when a given element isn't built and destroyed over and over again, creating the core elements only once and then re-using them over and over again seems the most logical route to take.

Add to both the above, since the likelyhood of mousing over two elements requiring tooltip service is low or at least can be minimized by using a logical page/element layout, the need for more than one tooltip to be visible at any one time can be reduced to zero.

But, since the initial construction takes almost no time at all we will wait to actually construct the core elements until there is an actual request to instantiate a tooltip and make it visible.

So, during the initialization of the tooltip core elements, we will construct the container div and the two images used for the upper and lower pointers and then assign them classNames so that they display properly.

Note : The most common cause of these tooltips not showing up is one forgetting to set/include the necessary CSS information in a linked to style sheet or inlined, with an external/imported style sheet being preferred.

Construction completion and display

Once there is a need for a tooltip to be displayed, the tooltip constructor is called passing it, among other things, the "contents" of what it is to display.

I put "contents" in quotes because the function does not pass actual HTML elements but instead, their string representation that can then be used to construct the elements themselves.

The actual construction of the contents based on the input string can be performed simply by using what has become a defacto-standard, innerHTML or, by iteratively instantiating each element as the input string is parsed, the latter of which will be documented in a future project.

But, since I haven't documented Javascript HTML parsing and element instantiation at the time of documenting this project, I'll use the "cheap and dirty" method of using innerHTML.

In any event, we at this point have a fully constructed tooltip and are ready to display it, almost. We also have to locate and orientate the tooltip to its proper place on the page and the correct, upper or lower, pointer image visible and positioned accordingly as well.

Here is where the "fun" begins. It is the algorithms used to locate and orientate the tooltip's elements that give this tooltip its advanced display functionalities.

Placement and orientation...

Tooltip placement and orientation

Historical perspective

For a tooltip to be of use, it of course has to be visible and for it to be of use as opposed to a hinderance, it should not get in one's way or become a distraction causing one to lose one's place in the flow of a document.

When one is reading text the mind maintains a sort of "back-buffer" that maintains an image of what has been read already allowing one to easily and quickly determine where one has been in a document which then leads to determining where one is currently.

If you break that link, between the mind's "back-buffer" and the page, it will take the mind a short time to relocate itself back to where it was just previously.

Fortunately for computer users, the creators of the ubiquitous tooltip we have all come to count on when in need of just slightly more information gave us a tooltip that doesn't get in the way. When it appears, it does so below and slightly to the right of where ever it is that the mouse is currently.

But, what happens if where the mouse is is at the bottom of a page? The answer to that varies widely and depends on a given application's implementation but the same question asked of the tooltip functionality documented here is simple, the tooltip will always be in the least distracting location and always visible.

Position awareness

The tooltips documented here are position aware. They know where they are on a page as well as how close to its borders they are.

Being aware of their location on a page allows them to always position themselves to be visible and worst case, least distracting.

For example, when in the center of a page with no borders potentially restricting its visibility, these tooltips will display, as the original tooltips do, below and to the right of the mouse position.

If the mouse is close to the top edge of the page, the tooltip being below the mouse never leads to a problem but if the mouse is located towards the bottom of the page, the tooltip then risks being positioned off the bottom of the page and partially or fully hidden from view.

In this case, being located near the bottom of the page, the tooltip senses that its body would be partially, or fully hidden by the bottom border and accordingly switch its position to being above the mouse. This is of course sub-optimal from a page flow point of view but considering the alternative, not being displayed at all, there is not much one can do.

Besides tooltips disappearing off the bottom of a page, the next and maybe worse problem is being displayed partially off the right side of the page. Rarely is the left side of the page a problem but a tooltip that is partially hidden in the middle of its text is virtually worthless.

The tooltips documented here however will detect when they are near, on or beyond the edge of the page and reposition themselves, or even resize themselves if necessary, so that they are completely visible. In addition, you'll notice that the pointer "connecting" the tooltip to the mouse pointer will actually slide along the tooltip left to right and back again so that the mouse pointer and tooltip pointer always coincide.

Tooltip mechanics

Once a tooltip has been made active, every time the mouse is moved, not only are calculations performed to determine where the tooltip itself should be displayed in relation but more so, where the edges of the page are so that it can also check to make sure that where it moves to, won't end up with it being partially or even totally hidden.

Using the viewport's height and width as well as the page's top and left scroll position, the tooltip can determine exactly where it is and slide left-right, resize or flip to above or below the mouse position as needed.

On to the code...

Theory implemented

Unfortunately the code section of this article is not yet complete but should be availabe in the very near future. In the mean time, feel free to examine the site's cas_tips.js file to pick it apart for yourself.