This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 7736 - add tooltip attribute & keep title for other uses
Summary: add tooltip attribute & keep title for other uses
Status: CLOSED WORKSFORME
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML Microdata (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P3 enhancement
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: NE
Depends on:
Blocks:
 
Reported: 2009-09-26 22:11 UTC by Nick Levinson
Modified: 2010-10-05 13:03 UTC (History)
5 users (show)

See Also:


Attachments

Description Nick Levinson 2009-09-26 22:11:36 UTC
The title attribute has multiple uses, sometimes confusingly. They mainly support tooltips. In the abbr and old acronym elements, they commonly support both tooltips and text-to-speech (TTS) pronunciations. In another element or two or so, they have other uses.

While tooltips are often positive, they can interfere with a user experience when they pop up but don't add useful information or even are interesting. To turn them off requires not having the title attribute but that denies text-to-speech support (in their absence, TTS generates default pronunciations, which may be wrong and even hard to comprehend).

E.g., the form "<abbr title="+15553676287">+1-555-FORMATS</abbr>" is required in the hCard spec (http://microformats.org/wiki/hcard (as accessed 9-22-09)) but it leads to a TTS error if the page author wants TTS to say "1 5 5 5 formats". The error is not W3C's but is due to a shortage of attributes to serve the range of needs in the wild.

A more semantic and dedicated attribute would clarify page authors' intentions.

I propose a tooltip attribute for most or all elements that could appear in a body element.

The title attribute should be kept for other uses but its use for tooltips should be deprecated.

Thank you.

-- 
Nick
Comment 1 Maciej Stachowiak 2009-09-29 07:39:25 UTC
Wouldn't it be more useful to have an attribute for descriptive information that doesn't display as a tooltip at all, either in future or existing browsers? Then title="" can then be reserved for use cases that do want a tooltip. Adding a tooltip attribute would not solve the problem that the abbr markup you cited produces a tooltip.
Comment 2 Ian 'Hixie' Hickson 2009-09-29 11:00:18 UTC
The example you give is non-conforming HTML5; title="" isn't allowed to be used like that per HTML5.

Microdata uses <meta> for including data like this.
Comment 3 Nick Levinson 2009-10-04 23:02:55 UTC
> Wouldn't it be more useful to have an attribute for descriptive information that doesn't display as a tooltip at all, either in future or existing browsers? . . . .
Either approach would fulfill demand and either approach would have the same problem of version compatibility. Since there's a general goal of keeping HTML and other languages semantic, I think an attribute meant for tooltips should be called tooltip, and something for multiple or residual uses should have a more general name, for which title, already established, will do.

> title="" isn't allowed to be used like that . . . .
Okay, thus the need for more methods to satisfy needs.

Use for TTS seemed to be widespread a while back, causing a usability conflict with tooltips use.

Both TTS and microformats have good use cases, and both are being shoehorned into the title attribute. We should hand out a more comfortable shoe, i.e., a more semantic attribute.

> Microdata uses <meta> for including data like this.
No, as to microformats. And that's complicated.

They don't use meta now (<http://microformats.org/wiki/hcard>, Property Notes, n. 2, & Human vs. Machine readable, as accessed 10-3-09). The latter says, "If an <abbr> element is used for a property, then the 'title' attribute (if present) of the <abbr> element is the value of the property, instead of the contents of the element, which instead provide a more human presentable version of the value."

If they should use meta, they'll have to amend, but using meta in a head makes parsing of an hCard microformat in a body much more complicated, because page authors will have to write much larger heads and engines will have to apply many more steps. Adding an attribute seems simpler.
Comment 4 Ian 'Hixie' Hickson 2009-10-18 10:21:54 UTC
I didn't say microformats, I said microdata.

As far as I can tell, <meta> is the solution to your request.
Comment 5 Nick Levinson 2009-10-18 21:12:39 UTC
My errors in conflating microdata and microformats, as acknowledged in <http://www.w3.org/Bugs/Public/show_bug.cgi?id=7800#c2>, when I saw the new provisions, and in not noticing till now that now meta is allowed in body for flow and phrasing if it has the itemprop attribute.

Thanks.
Comment 6 Maciej Stachowiak 2010-03-14 14:51:51 UTC
This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
  http://dev.w3.org/html5/decision-policy/decision-policy.html

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.