What is generally discouraged? By whom?

[[Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification (e.g. requiring a pointing device such as a mouse to cause a tooltip to appear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet).]]
(WHATWG HTML spec, 3.2.5.2 The 'title' attribute)

You are suggesting to convey important information in a way the spec itself discourages.

[[The abbr element represents an abbreviation or acronym, optionally with its expansion. The title attribute may be used to provide an expansion of the abbreviation. The attribute, if specified, must contain an expansion of the abbreviation, and nothing else.]]
The most urgent case. This element has no other technical way to convey its expansion, besides the prose but it is not clarified how.

[[If the dfn element has a title attribute, then the exact value of that attribute is the term being defined.]]
Second case in order. Its defined term can also be the text content, or the @title of the child <abbr> element. But sometimes its own @title would be useful.

[[<menuitem> - The title attribute gives a hint describing the command, which might be shown to the user to help him.]]
Third case. There is no other way to provide additional hints but usually the @label could be useful. Anyway, being an interactive element, at least in some devices @title can have visibility as long as UA highlights the tooltip on focus.

[[When an input element has a pattern attribute specified, authors should include a title attribute to give a description of the pattern. User agents may use the contents of this attribute, if it is present, when informing the user that the pattern is not matched, or at any other suitable time, such as in a tooltip or read out by assistive technology when the control gains focus.]]
Fourth and last in order. <input> is interactive, so it can have action based on it being focused. And its @title is "special" only in tandem with @pattern (<input> already has its own expansion, the <label> element.

So, the most important cases are non-interactive elements. In visual UAs, their tooltip would overlap their parent's @title tooltip, which is maybe useful as auxiliary information, but must be sacrificed because there are no alternatives for expansions. What happens in the other UAs, such as touchscreen devices, WebTVs, AT? How is that attribute meant to be shown?

Right, the recommendation is against relying on it. <abbr> and <dfn> are hardly critical cases (even if all browsers showed title="" on request, it's not like every reader is going to bring up the tooltip), so it's not a huge deal. If it's critical information, include it inline ("<abbr>LT</abbr> (Like This)").

<menuitem> and the pattern title aren't affect by the issue of browsers not showing title="" in general, since they have dedicated support (e.g. the pattern title text appears in the message about the pattern not being matched).

Anyway, the correct solution is for browsers to just implement title="". The browsers don't support anything else for <abbr> and <dfn> either, so introducing another new feature wouldn't help either.

The spec already says how to implement it:

# On interactive graphical systems where the user can use a pointing device,
# this could take the form of a tooltip. When the user is unable to use a 
# pointing device, then the user agent is expected to make the content available 
# in some other fashion, e.g. by making the element a focusable area and always 
# displaying the advisory information of the currently focused element, or by 
# showing the advisory information of the elements under the user's finger on a 
# touch device as the user pans around the screen.
#
# For example, a visual user agent could make elements with a title attribute 
# focusable, and could make any focused element with a title attribute show its 
# tooltip under the element while the element has focus. This would allow a user 
# to tab around the document to find all the advisory text.
#
# As another example, a screen reader could provide an audio cue when reading an 
# element with a tooltip, with an associated key to read the last tooltip for 
# which a cue was played.

(In reply to Ian 'Hixie' Hickson from comment #3)
> Right, the recommendation is against relying on it. <abbr> and <dfn> are
> hardly critical cases (even if all browsers showed title="" on request, it's
> not like every reader is going to bring up the tooltip), so it's not a huge
> deal. If it's critical information, include it inline ("<abbr>LT</abbr>
> (Like This)").
> 
> Anyway, the correct solution is for browsers to just implement title="". The
> browsers don't support anything else for <abbr> and <dfn> either, so
> introducing another new feature wouldn't help either.
> 
> The spec already says how to implement it [...]

I read the spec about it. I don't think that UA different from desktop browsers and/or not directed via a pointing device will ever do that, because they'd have to do it on every element which could support it (i.e. everywhere, since @title is global).
Anyway it _can_ become critical and the text could exclude the extended term(s) from the prose (because for example once it has been read it is no longer needed, and in small devices space is important). In addition to this, if the expansion were served depending on the acronym/defined term itself, the reference could point to the term together with expansion. If it's in the prose it can disperd.

In desktop browsers with pointing devices, instead, there's another issue, i.e. pointing the mouse on the acronym/defined term I see the title (needed for the expansion) but eventual @titles coming from the parent element are lost (e.g. an <a> element, or a <code> wrapping a piece of programming language where I want to define both an explanation of the code AND of a single statement/shortened name for a variable; as spec shows, there's no limit to real cases).

A very little suggestion: a new attribute, such as @value on <data>, with a new tooltip (signaled maybe with a sign near the word, such as WHATWG(?), expandable on focus in every UA, specific to those elements who need it (abbr, dfn, perhaps menuitem, NOT input for the reason you said above), whose expansion does not exclude the @title tooltip from parent elements. Something that in visual UAs can also be selected (for copypasting actions). Why new attribute instead of old  attribute with new behavior?
1. @title is so widely implemented that no vendors will change their mind on something that generic
2. new features today push for new support tomorrow.
I know that today's web is the web of apps and user-specific content, but text pages and text-level semantics are still important and can benefit from new features.

Why is doing it on every element a problem? It's the same as tooltips on every element on desktop, no?

I don't see any point adding a new feature here when we still haven't gotten a good implementation of the existing feature. It would be different if the existing feature was well-implemented but had problems we couldn't work around. But it's not implemented at all on an entire class of devices.

(In reply to Ian 'Hixie' Hickson from comment #5)
> Why is doing it on every element a problem? It's the same as tooltips on
> every element on desktop, no?
> 
> I don't see any point adding a new feature here when we still haven't gotten
> a good implementation of the existing feature. It would be different if the
> existing feature was well-implemented but had problems we couldn't work
> around. But it's not implemented at all on an entire class of devices.

Maybe I'm doing that much for nothing, I know. But the issue of tooltips excluding each other seems serious.
I was suggesting a way to convince other classes of devices to implement it for the first time, and the most widespread class (desktop browsers) to implement it in a new way.
How do you work around the problem of the <abbr> tooltip hiding the father element's tooltip, while keeping both of them visible and keeping the acronym's extension out of the text but still connected to the short form?
<a title="WHATWG home page" href="http://www.whatwg.org/"><abbr title="Web Hypertext Application Technology Working Group">WHATWG</abbr></a>

You don't. What's the purpose of the "WHATWG home page" tooltip? Almost nobody is going to know that it's there in the first place (even on desktop), and it's pretty obvious that the link is to the WHATWG home page since the URL is "http://www.whatwg.org/" and the link text is "WHATWG".

I would write that snippet as:

   <a href="http://www.whatwg.org/">WHATWG</a>

...with no <abbr> and no tooltip.

If you REALLY wanted both to be visible, you _could_ do it like this:

   <abbr title="Web Hypertext Application Technology Working Group">
   <a title="WHATWG home page
   Web Hypertext Application Technology Working Group" 
   href="http://www.whatwg.org/">WHATWG</a></abbr>

...but I think this is a bit of an edge case and it's fine to not support it.

Most platforms (e.g. Windows) don't support showing multiple tooltips either, by the way. If you hover over a button with a tooltip that is in a toolbar with a tooltip, only the button's tooltip shows.

Please reopen this bug if I missed some key use case that we should support.