The poorly supported title attribute
For such an important attribute, it’s strange that the title attribute doesn’t have better support than it does in modern web browsers. title is used to provide secondary descriptive text about an element, often rendered as a tooltip on mouse hover. Unfortunately, all major web browsers have bugs with whitespace and/or character reference handling on this attribute, making the feature often unusable for multiple-line texts.
I have constructed a title attribute tooltip test suite which I would like all major browsers to pass. Currently, Internet Explorer, Firefox, Opera, Safari, and Konqueror all fail at least one of the tests.
Internet Explorer allows line breaks in the tooltip value, but in the incorrect manner: it will display a line break if there are newlines or carriage returns in the source HTML. Newlines in the attribute source should be ignored and carriage returns should be converted to spaces, as in other CDATA attribues. The proper way to represent a line break in the attribute value is to use a newline character reference ( ), which Internet Explorer also (correctly) converts into a line break. IE also handles tab characters in the source incorrectly.
Firefox has perhaps the most disruptive bug, which limits the tooltip text to a small number of characters on a single line. Progress on fixing that bug is blocked by another bug relating to the calculation of tooltip heights. Firefox also has several problems with newlines, carriage returns, and tabs in the source HTML and doesn’t convert newline character references into line breaks. This is overall the worst implementation of the title attribute of all major browsers.
Opera fares well in the whitespace handling, but it doesn’t convert newline character references into line breaks, making multi-line values impossible.
Safari makes line breaks on newlines and carriage returns in the source and uses tab characters for wide spacing instead of ignoring the newlines and converting carriage returns and tabs into spaces.
Konqueror generally does well, but it handles newline characters in the source like Internet Explorer does. I would say this is the best implementation so far, although still not perfect.
With the growing amount of web-based applications aiming to provide the functionality and feel of traditional desktop applications, proper tooltip display of the title attribute value is becoming increasingly important. Please petition the browser developers for attention to this issue.
Edit: I’ve corrected the link to the Firefox bug report. The previously linked report was specifically for Mozilla/SeaMonkey.
September 2nd, 2006 at 13:31 UTC
Amen to this post!
I’ve been following the Firefox bug over at bugzilla (which is how I found out about this post) and find Firefox’s implementation way beyond annoying. It is also way beyond absurd that it still exists six years after first being reported.
I make very heavy use of the TITLE attribute to provide “meta data” about links and to define technical terms acronyms and would like to make even more use of it if it were better supported.
The title attribute could be a very powerful tool that would eliminate the need for JavaScript hacks that are not “accessible” by browsers that do not support JavaScript.
What is sad is that MSIE seems to be the browser that handles the TITLE attribute the best of the browsers, and MSIE6 is at least six years old. The developers of Firefox and the other “modern” browsers should almost be ashamed of being beaten by MSIE when it comes to this issue.
An example of a page that makes heavy use of the TITLE attribute is http://environmentalchemistry.com/yogi/chemicals/cn/Hydrochloric%A0acid.html. Again, I’d make even heavier use of the TITLE attribute if I could.
Come on OSS browser developers, are you going to let Microsoft show you how it is done when it comes to the TITLE attribute or are you going to lead the way and implement complete support for the TITLE attribute? Again, fixing this issue will eliminate the need for JavaScript to handle this functionality thus allow website developers to improve accessiblity of their sites for the disabled.
Posted using Mozilla Firefox 1.5.0.6 on Windows.
September 2nd, 2006 at 13:41 UTC
I have to disagree on the importance of such bugs. As you correctly mention, the title attribute is “often” rendered as a tooltip; its actual method of rendering is not explicitly defined in the HTML specification, so your assertion that the title attribute can be used to provide tooltip functionality is invalid (although common). If a particular rendering behaviour is required, it should be implemented manually, rather than relying on non-deterministic behaviour.
Just my $0.02.
- P
Posted using Mozilla Firefox 2.0b on Windows.
September 2nd, 2006 at 15:30 UTC
Getting web browsers to properly support the TITLE attribute…
It is very frustrating that web browsers, particularly Firefox, do not properly support the TITLE attribute as it is laid out in W3C HTML specifications. This isn’t a trivial matter; it is a major usability/accessibility issue. Without browsers proper…
Posted using (Unrecognized).
September 2nd, 2006 at 15:51 UTC
Penagate: It’s true that there is nothing in the HTML specification requiring the user agent to display the value in a tooltip. However, it is assumed that the user will have access to this information by some means. Whether that means is a tooltip, a browser frame, spoken text, etc. doesn’t matter as long as the information is made available to the user as it is defined in the source. Presently, the major browsers don’t provide the information properly intact: they choke on the whitespace and/or character references. This can to some degree change the meaning and context of the information.
Posted using Mozilla Firefox 1.5.0.6 on Linux.
September 2nd, 2006 at 17:27 UTC
I think that David Hammond’s comments in post #4 sum up the issue and address Penegate’s comment #2 very well. Also if people bother to read the specification linked to on the “Test Suite” page (http://www.w3.org/TR/html401/types.html#type-cdata), I think they would see that the handling of the white space issue with the TITLE attribute is well laid out.
Posted using Mozilla Firefox 1.5.0.6 on Windows.
September 3rd, 2006 at 01:32 UTC
[...] (more…) [...]
Posted using WordPress 2.0.4.
September 21st, 2006 at 07:00 UTC
The spec says that the title attribute should be a short message. Every single example provided in the HTML 4.01 spec and in the WCAG or WAI documents used examples where the title attribute has 60 characters or less.
Title in a tooltip is exactly that kind of feature which can be easily, very easily abused on the web. First, the default font-size value for the default window os theme and with the default-normal font-size is 8px Tahoma in tooltips and it will stay visible for 6sec. And people in bug 45375 demanded that the title attribute may be able to render dozens of words during a fugitive 6sec. in a box of Tahoma 8px text.
“Link titles should be less than 80 characters, and should only rarely go above 60 characters. Shorter link titles are better.”
J. Nielsen, http://www.useit.com/alertbox/980111.html
Compared to the initial testcase in bug 45375: attachment 90744 had 138 words, 542 non-space characters and 688 characters (all in the title attribute)! Testcase in attachment 125683 mentioned in comment 84 had 175 non-space characters in the title attribute!
Tooltip text is much more constraining for the user, limitative than one could think:
- the user can not copy and paste the text appearing in a tooltip,
- the user can not resize the text-size on the fly,
- the user can not see the title attribute value if he’s using keyboard navigation in any/all browsers I tested this: no tooltip, nothing,
- the user can not resize tooltip box,
- the user can not resize the text-size unless he knows where in the os,
- the user can not modify the time/duration of appearance of the tooltip
etc..
and for all these reasons, web developers should not put anything primordial in it, web developers should not put long (over 128 characters IMO) content in it, web developers should not put anything besides complementary info, advisory info
in it, just like HTML 4 and WAI are explicitly saying.
Re-hovering a link (over and out) or any tooltip-able element is not more user-friendly.
If tooltip text should wrap to show large amount of text, then so should the statusbar: it should expand, should stretch and wrap when the window.status message exceed the available number of characters for the message area, so that it would be
displayed entirely and not be cropped like it is now in IE, Mozilla, Opera. Same logic.
And why stay there. The title bar should expand, stretch and even wrap if the web author put in <title> 150 words. Same logic.
Gérard
Posted using SeaMonkey/Mozilla Suite 1.5a on Windows.
September 21st, 2006 at 09:11 UTC
Gérard: The titlebar issue is not the same thing. Firefox doesn’t arbitrarily cut off the titlebar text are a small number of characters. If the browsing window is large enough, the full title will display. But regardless of the window size, screen resolution, or anything else, Firefox unnecessarily limits the tooltip content length. You’re right that web developers should limit the amount of title attribute text for usability reasons, but that’s no excuse for the web browser deliberately hiding the rest of the value from the user. If a title attribute is provided, no matter how long it is, the web browser should do its best to provide the full value to the user within reason, and there is no reason not to use a lot more screen space than Firefox uses for tooltips if the value demands it.
Posted using Mozilla Firefox 1.5.0.7 on Linux.
September 21st, 2006 at 18:30 UTC
> If the browsing window is large enough, the full title will display.
Someone in bug 45375 has said that the limit of the title attribute should exceed the browser window itself!
Browsing window as the inherit limit is promoting and supporting bad webpage design and bad usability principles to begin with.
> Firefox unnecessarily limits the tooltip content length
It has an arbitrary limit but then what should be the limit for a tooltip? I’ve asked at least 3 times people in bug 45375 how many characters they can read in 6 sec. in a box of Tahoma 8px text? No one answered.
And tooltips can affect almost any types of elements, even a <p>!
> that’s no excuse for the web browser deliberately hiding the > rest of the value from the user
UAAG 1.0 has provided several answers on conditional content. I can read the title attribute thanks to the properties menu item from the context menu: it’s not perfect but the “full” content of the title attribute is accessible.
> If a title attribute is provided, no matter how long it is,
> the web browser should do its best to provide the full value > to the user within reason
Sorry, but I disagree. It does not work like that and it shouldn’t work like that. There is a limit to how much C++ code should go into a default browser behavior (some have again explained that the browser should calculate at run-time duration of tooltip, box dimensions, line-wrapping, etc. for tooltip). There is a limit to how much an user can read in 6sec. inside a box of Tahoma 8px font. There should be a limit to how many characters should be displayed in a tooltip before cropping the rest/excedent, just like <title> vs titlebar and window.status and the statusbar message work.
If the HTML 4.01/WAI/WCAG/UAAG specs did not explicitly defined how many characters are supposed to mean
“short message”, “short description”, “advisory title”,
“informative link title”
and the opposite side certainly avoided to define what was long enough, sufficient text length and any kind of quantitative value for text length. How many characters mean “long”, “normal”, “long enough” is nowhere defined. And one has to define this before defining when and where to line-wrap if line-wrap becomes necessary.
So far, all I got from a coding perspective is calculations for timers to be started at run-time for duration of tooltips! Just imagine the performance issues (pointers in memory, timers’ dependencies, storing values, etc) as one just moves the mouse over tooltip-able elements
Gérard
Posted using SeaMonkey/Mozilla Suite 1.5a on Windows.
September 21st, 2006 at 20:04 UTC
I’m not sure why you’re focusing on the (again arbitrary) 6-second limit. I and others believe that the tooltip should remain visible as long as the user needs it, so there should be no 6-second limit.
The title attribute can contain useful information and there is an obvious and common user interface feature (tooltips) to provide access to the value. I see no reason that the user interface feature should limit the amount of information that the user can access when providing more would not cause any significant loss of usability (in fact, I don’t think it would cause any loss of usability). Firefox doesn’t cut off the title at 25 characters if there is more room available, and I see no reason it should limit tooltips. In fact, the reasons so far presented have been technical issues relating to the vertical sizing of the tooltip box, not because it was a design choice to maximize usability. Limiting the displayed value and display time does not improve usability and it does hurt it in many cases.
Posted using Mozilla Firefox 1.5.0.7 on Linux.
January 16th, 2008 at 20:52 UTC
It is very frustrating that web browsers, particularly Firefox, do not properly support the TITLE attribute as it is laid out in W3C HTML specifications. This isn’t a trivial matter; it is a major usability/accessibility issue..
Posted using Internet Explorer (Windows) 7.0 on Windows.
December 14th, 2011 at 14:45 UTC
I have a concern for the title/ alt attribute for the anchor tag.
=>> Do we have any text limit for tooltip in IE/FF/chrome or any of the well know browsers? If we have text limit do we have any other hack to give long tooltip for anchor tag.
Posted using Safari 535.2 on Windows.