Posted using (Not Specified) .

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 (Not Specified) .

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 (Not Specified) .

Posted using (Not Specified) .

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 (Not Specified) .