An add-on: is that correct to suggest authors to rely on @title in special cases? The spec states that its use is "discouraged" because of its unreliability whenever the document is accessed without the use of a pointing device (so I think it refers to touchscreen devices, desktop browsers during keyboard navigation and TV with web navigation. For <abbr> and <dfn> it could be useful with printers. I don't know what happens with a screen reader, I suppose there are ways to voice its value but I'm not sure). Therefore the possible solutions are: 
- special rules for <abbr@title>, <dfn@title> and <menuitem@title> to show the attribute in other ways, e.g. as text after the proper content (printers) or tooltip on focus(TV)/prolonged "selection" action (touchscreen);
- the addition of another attribute with the behavior described before. Lately the extension of @value makes me think about it. @value is often an attribute whose value takes part in the rendering of the element (<meter>,<progress>: the value of the gauge/progress bar; <li>: the ordinal value in the specified list style).

It should be noted, however, that providing a way to make @title accessible with such UAs/devices/navigation modes, however, could be a problem because really many elements could have a @title in a document.

Finally, also in common desktop UAs, being forced to use a @title in order to convey specific explanations can be a problem because it interferes with parent element's @title (an example: <a href="http://www.w3.org/TR/CSS2/" title="W3 CSS2 Specification document"><abbr title="Cascading Style Sheet 2nd edition">CSS2</abbr></a>; the <a@title> could be useful but it is difficult to access).

For these 2 reasons I suggest allowing a @value in elements where an explanation is more relevant, and then giving authors the choice whether to rely on native @title tooltip or to work with a different item. In the long run, user agents could also define new ways to convey this information, e.g. to implement a focus-tooltip mechanism. If the cases are separate, then new mechanics can focus on the "special" case (a @value used only on elements which are more likely to be explained, a specialised version of RDFa ubiquitous and therefore useless @content) [or maybe enabled separately via a "settings" panel].

Last thing then I shut up. @value could be also passed to Microdata in the way I said before, as RDFa does with @content but in my opinion it is pointless, because it is ubiquitous and can be used when the element content IS sufficient. Sometimes, however, <dfn> and <abbr>'s extension/specification is worth passing to structured data, more than the content:
<article itemscope itemtype="http://schema.org/Article"><abbr value="Web Hypertext Application Technology Working Group" itemprop="about">WHATWG</abbr> is an unofficial collaboration of Web browser manufacturers and interested parties who wish to develop new technologies designed to allow authors to write and ...</article>

<input>'s use of title="" is with the pattern="" attribute.
See the bottom of:
   http://www.whatwg.org/specs/web-apps/current-work/#the-pattern-attribute

Use of title="" is discouraged today, but only because implementations have failed to do the right thing and implement it. The real solution is for ATs and so forth to do a better job exposing the title attribute. It'd be silly if we had to drop this annotation mechanism in favour of another one just because they haven't implemented it — after all, why would they implement the other.

I didn't follow the bit about microdata. Can you elaborate?

As a general rule, please file one bug per issue. Thanks.

(In reply to Ian 'Hixie' Hickson from comment #3)
> <input>'s use of title="" is with the pattern="" attribute.
I hadn't seen the final reference. Perhaps it would be good to insert this in the introductory box as in other elements.

I will reply here once more about @title-specific semantics. Please move the relevant messages if for some reason you can find it useful.
The first time I thought about this, it wasn't really for a matter of implementation or visual annotation. It was about microdata.
I think there could be cases when the extended/explained content of an abbr or a dfn element could be passed as a Microdata property (need thinking more for menuitem for obvious reasons). For what I know, Microdata never use @title while it could be useful, for example, as an article topic when specified on a <dfn> element. 
<dfn itemprop="about" title="HTML paragraph element">&lt;p&gt;</dfn> represent an autonomous span of text.
Sort of. In scientific essays this happens even more often. So I thought Microdata could consider the @title of elements where this has a strong semantical value (even more in <abbr>). But it would configure a new special case.
Then I thought about the limits of @title, as said before. Mainly limits of interaction/conflict with parents' or children's @title. If this semantic were conveyed by a new attribute, all the conflicts would be avoided. Now I can't use @title on an abbr/dfn and on the parent/children element if they overlap too much. 
Last thing, the explicitation mechanism. Indeed it hasn't been done in limited user agents or devices because it would make the navigation slower if such UA had to show all the titles in a document. Then they should use special rules if they wanted to show extended forms of acronyms or terms. If we had a new attribute, UAs could explicitate this last one, only where needed.
Text-level elements can seem trivial but for a lot of documents they are still important.
Sorry again and thanks.

(In reply to Andrea Rendine from comment #4)
> I hadn't seen the final reference. Perhaps it would be good to insert this
> in the introductory box as in other elements.

Done. (I hadn't realised this was missing.)

Checked in as WHATWG revision r8304.
Check-in comment: Fix up the attribute annotations a bit
http://html5.org/tools/web-apps-tracker?from=8303&to=8304

> The first time I thought about this, it wasn't really for a matter of
> implementation or visual annotation. It was about microdata.
> I think there could be cases when the extended/explained content of an abbr
> or a dfn element could be passed as a Microdata property (need thinking more
> for menuitem for obvious reasons). For what I know, Microdata never use
> @title while it could be useful, for example, as an article topic when
> specified on a <dfn> element. 
> <dfn itemprop="about" title="HTML paragraph element">&lt;p&gt;</dfn>
> represent an autonomous span of text.

It's not clear to me when you would do something like this. do you have a real-world example of something like this?


> Sort of. In scientific essays this happens even more often. So I thought
> Microdata could consider the @title of elements where this has a strong
> semantical value (even more in <abbr>). But it would configure a new special
> case.

Again, if there's a concrete example of this, that would help. In examples I can think of, you'd want the microdata to express what the user can read on the page... that's kind of the point.


> Then I thought about the limits of @title, as said before. Mainly limits of
> interaction/conflict with parents' or children's @title. If this semantic
> were conveyed by a new attribute, all the conflicts would be avoided. Now I
> can't use @title on an abbr/dfn and on the parent/children element if they
> overlap too much. 

Not sure what you mean here.


> Last thing, the explicitation mechanism. Indeed it hasn't been done in
> limited user agents or devices because it would make the navigation slower
> if such UA had to show all the titles in a document. Then they should use
> special rules if they wanted to show extended forms of acronyms or terms. If
> we had a new attribute, UAs could explicitate this last one, only where
> needed.

Not sure what you mean here either.

Please re-open if you respond to comment 7. Thanks.