If the page provides structured data (e.g. but not only limited to, markup via Microdata), it can be useful to pass as property value the extended form of the acronym (e.g. Web Hypertext Application Technology Working Group, instead of WHATWG) or the specific form of the defined term (e.g. in a case like this: <dfn title="HTML 'body' element">&lt;body&gt;</dfn>). It can be achieved in two ways:
 - creating new element-specific rules in Microdata, which would make it more confusing
 - allowing the use of a different attribute on <dfn> and <abbr>.
Judging by the case and by previous confrontations about this matter, I would suggest to allow the use of @value attribute in these elements for several reasons:
 • @title says nothing about the real meaning of the attribute content, using it means stretching its use ("the title attribute represents advisory information for the element").
 • for these elements @title has to be treated differently than in every other element, thus forcing a specific syntax for a global attribute.
 • @title can present conflict with other, more generic uses of the @title attribute. e.g. an author could prefer inserting other indications as "title tooltip", while he's somehow forced to use it in the requested way. Or the <abbr> is inserted in another element (such as <a>) which has a title on its own: then the tooltip changes depending on the action: mouse over <a>/mouse over <abbr>
 • the most important: this use of @title is useful only for desktop browsers with pointing devices (the typical "tooltip" behavior of @title), while it is completely useless in touchscreen devices without a cursor, or with keyboard navigation. This is already highlighted by the spec, but here's a FORMAL use of it. As an alternative, the author must provide an internal way for showing it (and it can come in conflict with the original tooltip). Using a brand-new attribute would bring authors, and maybe user agents, to show its value in a more accessible way (e.g. on focus).
 • finally, it would lead to a consistent use of @value, both from a theoretic and a semantic point of view, in addition to finally enabling Microdata parsing of @value in all the elements where it is or can be present.

Can you give a concrete example of how this would be used? Like, a real Web page showing how people are doing it now, and then a strawman showing how they could do it if we implemented this? I'm not really sure I understand how this would work.

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

Here's a direct example. Document fragment, use of Microdata. A use case on <abbr>. Please remember:
1. It's text markup. There is plenty of ways to do the same things in the wild. It can happen that this is neither the only one, nor the most efficient one. But it could be enabled quite easily and maybe it would work.
2. It's an alternative to what is done now, it is not meant to substitute practices consolidated throughout decades. It wouldnt be too difficult to allow,just making it "legal" would suffice.
3. Who implements it can easily decide how to render it thanks to CSS, so if it were used it wouldn't suffer from lack of implementation on the side of UAs at the beginning. Of course IF it convinced you and IF it convinces UA manufacturers, this could lead to a consistent implementation in the future.

On with the example.
<section itemscope itemtype="http://schema.org/Person"> 
 <p>Hello, my name is <span itemprop="name">John Doe</span>.</p>
 <p>I work in Example Corp. as a <a href="http://example.com/staff/" title="Example.com - Staff page, information about roles in the Company"><dfn itemprop="jobTitle" title="Search Engine Optimization consultant">Googleman</dfn></a>, my job is that when you google out something we produce you can easily find us! </p>
 <p>My previous affiliation was with <a href="http://www.whatwg.org/" target="_blank" title="WHATwg home page - opens in new window!"><abbr itemprop="worksFor" title="Web Hypertext Application Technology Working Group">WHATWG</abbr></a>. </p>
</section>

The example is maybe quite radical for the choice of what text to mark up as hyperlink, but it's just to explain. On desktop browsers the <a> title is lost because the internal <dfn> / <abbr> fills it completely. So only the expansion for the 2 elements is available. Indeed it was inserted because it's useful in both cases, but there is no way to prevent the appearance of the title tooltip, so the container's title is lost.
On the other hand, in non-visual user agents both titles are lost for another reason. Screen readers and mobile browsers cannot easily implement access to @title (mobile devices don't do it) for 2 reasons: a. they lack a hover equivalent (but it could be with focus) and b. because @title is ubiquitous and implementing it everywhere would make the page messy.
The solution for me would be allowing @value on these elements. On desktop browsers they could be separate tooltips (maybe with a specific mark on them:
WHATWG(?)
as some pages do in order to offer an expansion to selected text). Also mobile devices could render this attribute. Why this and not @title? Because @value would appear on the elements which need it: abbreviations/acronyms and alternative definition terms. Also here, it could be rendered as described before, 
and tapping/focusing on the (?) an explanatory tooltip could appear.
From a theoretical point of view, @value says more than @title that an abbreviation is a short form for a longer term and substitutes it. In <dfn>, sometimes the text content is compatible with the prose, or user-familiar, while the real term to be defined must be given via the attribute. @title seems unappropriate.
Finally. I chose an example with Microdata for a purpose. In both cases the expansion of the <abbr>/<dfn> is the real value which one is interested to highlight with semantic markup (job:Googleman isn't serious). What if Microdata could read the attribute rather than the content? Then I suggested an existing attribute, @value, because it could be of some sense to read it wherever it's allowed, it always conveys a meaning.
It isn't worth as an issue but it could be useful.

I don't follow. What's wrong with this:

  <section itemscope itemtype="http://schema.org/Person"> 
   <p>Hello, my name is <span itemprop="name">John Doe</span>.</p>
   <meta itemprop="jobTitle" content="Search Engine Optimization consultant">
   <p>I work in Example Corp. as a <a href="http://example.com/staff/" 
   title="Example.com - Staff page, information about roles in the 
   Company">Googleman</a>, my job is that when you google out something we 
   produce you can easily find us!</p>
   <meta itemprop="worksFor" content="Web Hypertext Application Technology
   Working Group">
   <p>My previous affiliation was with <a href="http://www.whatwg.org/" 
   target="_blank" title="WHATwg home page - opens in new window!"><abbr
   title="Web Hypertext Application Technology Working Group">WHATWG</abbr></a>.
   </p>
  </section>

The problem with relying on title="" is that it becomes really confusing. As you point out, there's four title=""s in your example, so you have to be careful about which you're trying to use. It also becomes confusing when you have an element like <a> or <time> where there's another attribute that's supposed to be used for the data; now you have to worry about whether it's the attribute that wins or title="" that wins. Similarly, with <abbr> sometimes you want the itemprop="" value to be the short value and sometimes you want it to be the expanded value; it's simpler if we just don't make <abbr> magical and you have to be explicit about which you want.

This just feels like trying to be too clever, which was exactly the mistake that RDFa made and is why RDFa is such a mess.

(BTW, that <dfn> is probably not appropriate.)

(In reply to Ian 'Hixie' Hickson from comment #5)
> I don't follow. What's wrong with this:
> 
>   <section itemscope itemtype="http://schema.org/Person"> 
>    <p>Hello, my name is <span itemprop="name">John Doe</span>.</p>
>    <meta itemprop="jobTitle" content="Search Engine Optimization consultant">
>    <p>I work in Example Corp. as a <a href="http://example.com/staff/" 
>    title="Example.com - Staff page, information about roles in the 
>    Company">Googleman</a>, my job is that when you google out something we 
>    produce you can easily find us!</p>
>    <meta itemprop="worksFor" content="Web Hypertext Application Technology
>    Working Group">
>    <p>My previous affiliation was with <a href="http://www.whatwg.org/" 
>    target="_blank" title="WHATwg home page - opens in new window!"><abbr
>    title="Web Hypertext Application Technology Working
> Group">WHATWG</abbr></a>.
>    </p>
>   </section>
> 
> The problem with relying on title="" is that it becomes really confusing. As
> you point out, there's four title=""s in your example, so you have to be
> careful about which you're trying to use. It also becomes confusing when you
> have an element like <a> or <time> where there's another attribute that's
> supposed to be used for the data; now you have to worry about whether it's
> the attribute that wins or title="" that wins. Similarly, with <abbr>
> sometimes you want the itemprop="" value to be the short value and sometimes
> you want it to be the expanded value; it's simpler if we just don't make
> <abbr> magical and you have to be explicit about which you want.
> 
> This just feels like trying to be too clever, which was exactly the mistake
> that RDFa made and is why RDFa is such a mess.
> 
> (BTW, that <dfn> is probably not appropriate.)

I would never expect @title to be taken as property value! for the same reason you explained. RDFa has @content for this and it's disastrous because it can go everywhere! I would never like an ubiquitous attribute to be considered for this.
But in your example I'd have to set an exogenous element just to have microdata parsed. When I'm concerned with semantic markup, I want that my *existing* markup is parsed for its meaning, not to insert new stuff. Authors still don't use cleverly what they have at their disposal, and you can't convince them to even insert more things. You have to think to the *average* author too, not to the cleverest one only.
What I would like to see is this. We have <abbr> and <dfn>. There is no way an author would ever like to highlight the acronym rather than the expansion (even if the acronym is known as HTML or FBI, expanded is clearer). And if an expansion is needed in <dfn>, it's probably because it's clearer than the text content. 
Now, pretend I'm an author who wants to use these elements. I can do as you showed above. But why not having something cleaner which is ALSO (somehow) visible to the user in form of tooltip (for those who don't know what WHATWG is. Well, not so many indeed...)?
So I use the <abbr> or the <dfn>. Like <a@href> or <time@datetime> these elements can have the sort of magic you said for a very own attribute - @value - and what is passed to microdata is always that, if present, and not the content. And, which is even better, i can *show* that attribute as a tooltip without messing with other titles (just, the tooltip could be different). Because there's no meaning in having explanations in invisible elements. Explanations/expansion can be useful for end users too. It's just the same issue which brought to the <data> element, more compact than yours perhaps, more semantic and would allow to get rid of a special use case for a (somehow somewhere) poorly rendered attribute.

I don't understand. If you're ok with adding new attributes, why is adding a new element a problem?

I disagree that "there is no way an author would ever like to highlight the acronym rather than the expansion". The case of the WHATWG is a good example. It's actually more likely to be understood as its acronym than its expansion. In fact the same can probably be said of many things. If microdata is being used e.g. for annotating data for search results, you probably want the acronym and not the expansion.

(In reply to Ian 'Hixie' Hickson from comment #7)
> I don't understand. If you're ok with adding new attributes, why is adding a
> new element a problem?
Because a new attribute can be used for other purposes, as I said before. A @value can be used to display widgets in mobile devices or screen readers, if specs can encourage them to display a new, specific @value rather than the ubiquitous and generic @title. But also because attributes add information elements, which in turn describe content. It is the purpose of the markup language. A new element is pointless, it cannot be used to describe content. The cases of <data> and <time> underline this. In order to convey a machine-readable value for unreadable content, you chose to create new element with a specific attribute. It is coherent.

> I disagree that "there is no way an author would ever like to highlight the
> acronym rather than the expansion". The case of the WHATWG is a good
> example. It's actually more likely to be understood as its acronym than its
> expansion. In fact the same can probably be said of many things. If
> microdata is being used e.g. for annotating data for search results, you
> probably want the acronym and not the expansion.
Also in this case, a @value would solve it. If present, the content of semantic property is in the value and easier to understand. Otherwise in the content, and more compact/friendly.

I don't mean why are you ok with adding, say, value="". I mean, why are you ok with adding itemscope="", itemtype="", itemprop="", and so on, if you're not ok with adding <meta>?

(In reply to Ian 'Hixie' Hickson from comment #9)
> I don't mean why are you ok with adding, say, value="". I mean, why are you
> ok with adding itemscope="", itemtype="", itemprop="", and so on, if you're
> not ok with adding <meta>?

Actually it's quite obvious. It's the same idea which brought the WG to insert <time> as container rather than "side" element.
Follow the difference, both in meaning and in applicability:

   <meta itemprop="jobTitle" content="Search Engine Optimization consultant">
   <meta itemprop="worksFor" content="Web Hypertext Application Technology
   Working Group">
   <p>I work in Example Corp. as a <a href="http://example.com/staff/" 
   title="Example.com - Staff page, information about roles in the 
   Company">Googleman</a>, my job is that when you google out something we 
   produce you can easily find us! But my previous affiliation was with <a
   href="http://www.whatwg.org/" target="_blank" title="WHATwg home page - opens
   in new window!"><abbr title="Web Hypertext Application Technology Working
   Group">WHATWG</abbr></a>. </p>
First off, there's no reference to where in the paragraph such pieces of information are defined. Second, either I can't exploit them in any way for, say, widget or enhancing content syntax (for <dfn>) or I have doubled the data uselessly, once for HTML syntax and once for semantic markup (<abbr@title> + <meta>). Third, there is a necessary overlapping in the case of <abbr> as both link explanation and acronym expansion, which are both things I want to make the user see, are expressed with @title and the outer one is not visible. Fourth, no information at all about expansion/explanation can be provided to non-visual UA users.

Now see this.
   <p>I work in Example Corp. as a <a href="http://example.com/staff/" 
   title="Example.com - Staff page, information about roles in the 
   Company"><dfn itemprop="jobTitle" value="Search Engine Optimization 
   consultant">Googleman</dfn></a>, 
   my job is that when you google out something we 
   produce you can easily find us! But my previous affiliation was with <a
   href="http://www.whatwg.org/" target="_blank" title="WHATwg home page - opens
   in new window!"><abbr itemprop="worksFor" value="Web Hypertext Application 
   Technology Working Group">WHATWG</abbr></a>. </p>
Cleaner, semantic markup MORE semantic because I use existing elements and I add them extended relevance, which is the purpose of semantic markup. Microdata adds attributes which define meaning, to existing elements. Otherwise we would simply add a bunch of meta elements in the <head> and that'd be all. 
Finally, as I said, these elements can be used for new kinds of widgets that don't overlap in desktop browsers and that mobile devices can be convinced to use instead of title.
It is a little issue but could encourage authors, who do not willingly add invisible tags when they're concerned in showing content to users.

(In reply to anakin_rendine from comment #10)
> First off, there's no reference to where in the paragraph such pieces of
> information are defined.

What kind of reference do you mean? Per the microdata model, the itemprop="" property doesn't set up any kind of reference either; while the microdata and HTML data models are overlapped on the same DOM, they do not reference each other. You can't get from a property to an element, in microdata.


> Second, either I can't exploit them in any way for,
> say, widget or enhancing content syntax (for <dfn>) or I have doubled the
> data uselessly, once for HTML syntax and once for semantic markup
> (<abbr@title> + <meta>).

I don't understand what you mean here.


> Third, there is a necessary overlapping in the case
> of <abbr> as both link explanation and acronym expansion, which are both
> things I want to make the user see, are expressed with @title and the outer
> one is not visible.

Not sure what you mean here either.


> Fourth, no information at all about
> expansion/explanation can be provided to non-visual UA users.

What's that got to do with microdata? I don't follow.


> Cleaner, semantic markup MORE semantic because I use existing elements and I
> add them extended relevance, which is the purpose of semantic markup.

Actually it's exactly as semantic. The HTML markup semantic is the same (modulo the addition of a "defining term" in the second one, but that seems bogus semantically), and the microdata data model is identical. There is nothing more machine-readable about the second than the first.


> Microdata adds attributes which define meaning, to existing elements.

Not necessarily existing elements.


> Otherwise we would simply add a bunch of meta elements in the <head> and
> that'd be all. 

Right. You can.

You can also use JSON in a <script> block, for example.

The only reason microdata generally tries to reuse the existing data on the page is that it makes it more likely that the hidden metadata won't get out of sync with the visible data. But when the data is somewhere microdata can't reach (e.g. a title="" attribute), you use <meta>.


> Finally, as I said, these elements can be used for new kinds of widgets that
> don't overlap in desktop browsers and that mobile devices can be convinced
> to use instead of title.

I don't understand this. What's this got to do with microdata?


> It is a little issue but could encourage authors, who do not willingly add
> invisible tags when they're concerned in showing content to users.

I don't understand this. How are authors who don't want to add "invisible tags" going to be encouraged to add anything? And why should we want to encourage them?

(In reply to Ian 'Hixie' Hickson from comment #11)
> (In reply to anakin_rendine from comment #10)
> > First off, there's no reference to where in the paragraph such pieces of
> > information are defined.
> 
> What kind of reference do you mean? Per the microdata model, the itemprop=""
> property doesn't set up any kind of reference either; while the microdata
> and HTML data models are overlapped on the same DOM, they do not reference
> each other. You can't get from a property to an element, in microdata.

[[annotate content with specific machine-readable labels]]
This is the purpose of Microdata. This is what I wanted to say. Microdata for labeling existing elements.


> > Second, either I can't exploit them in any way for,
> > say, widget or enhancing content syntax (for <dfn>) or I have doubled the
> > data uselessly, once for HTML syntax and once for semantic markup
> > (<abbr@title> + <meta>).
> 
> I don't understand what you mean here.

If i have only @title for expansions, of course I must insert acronym expansion elsewhere for microdata, thus writing it twice.

> > Third, there is a necessary overlapping in the case
> > of <abbr> as both link explanation and acronym expansion, which are both
> > things I want to make the user see, are expressed with @title and the outer
> > one is not visible.
> 
> Not sure what you mean here either.

Test my example, mouse over WHATWG and see if you can read the title on the link. If @value created a different type of widget (maybe focus widget instead of hover), the two wouldn't overlap and would be both visible.

> > Fourth, no information at all about
> > expansion/explanation can be provided to non-visual UA users.
> 
> What's that got to do with microdata? I don't follow.

Nothing. From the beginning I said that inserting a new @value for this would address multiple issues. This refers to the fact that I'm not sure whether screen reader access @title. But <abbr@title> and <dfn@title> are important. Their content could be expressed as @value instead, and read as a new feature by AT.

> > Cleaner, semantic markup MORE semantic because I use existing elements and I
> > add them extended relevance, which is the purpose of semantic markup.
> 
> Actually it's exactly as semantic. The HTML markup semantic is the same
> (modulo the addition of a "defining term" in the second one, but that seems
> bogus semantically), and the microdata data model is identical. There is
> nothing more machine-readable about the second than the first.

No it isn't, because the explanation is not connected to the part of content it aims to explain!!! (I know that I made a bad example for <dfn>, but the same issue can be elaborated over better cases if I had more fantasy).

> > Microdata adds attributes which define meaning, to existing elements.
> 
> Not necessarily existing elements.

There is RDF for new elements. The positive of Microdata, its step forward compared to RDF, is to add meaning to existing content. You yourself in a previous answer told me that the positive of Microdata is that it is built to work in parallel with HTML. And now for a so simple issue an author should add external elements? Can't it be done differently?
 
> > Otherwise we would simply add a bunch of meta elements in the <head> and
> > that'd be all. 
> 
> Right. You can.
> 
> You can also use JSON in a <script> block, for example.

See above.

> The only reason microdata generally tries to reuse the existing data on the
> page is that it makes it more likely that the hidden metadata won't get out
> of sync with the visible data. But when the data is somewhere microdata
> can't reach (e.g. a title="" attribute), you use <meta>.

Another good reason, and I could tell you another one. Inserting exogenous elements allows authors to insert data which differ from the actual content maliciously. Or simply carelessly.
@title cannot be reached. @value could. And it could serve more than one master.

> > Finally, as I said, these elements can be used for new kinds of widgets that
> > don't overlap in desktop browsers and that mobile devices can be convinced
> > to use instead of title.
> 
> I don't understand this. What's this got to do with microdata?

See above.

> > It is a little issue but could encourage authors, who do not willingly add
> > invisible tags when they're concerned in showing content to users.
> 
> I don't understand this. How are authors who don't want to add "invisible
> tags" going to be encouraged to add anything? And why should we want to
> encourage them?

Authors don't care that much about adding invisible elements. And authors who do it could exploit this feature in bad ways. Of course if I can do something in a proper, semantically elegant, machine+user readable and compact way, I prefer doing it instead of going back to RDF separated documents era.

(In reply to anakin_rendine from comment #12)
> Their content could be expressed as @value instead, and read as a new feature by AT.
Though I wrote as such for brevity, I meant not only assistive technology, but also user agents which don't support "widgets" on mouse hover for @title.
I can also open 3 separate bugs for the different issues (theoretic issue of a special semantic for a global attribute - widget overlapping - alternative for showing the expansion outside desktop browsers - semantic markup), but I preferred reuniting them in only one report, because they can all be solved with a new attribute IMO and I also didn't want to disperse your attention on too many texts.

> This is the purpose of Microdata. This is what I wanted to say. Microdata
> for labeling existing elements.

Actually not really. The purpose of microdata is to layer a separate data model over the top of the HTML DOM, so that the two data models can both be built within a single page without duplicating too much data. There's actually no real relationship between the microdata model and the HTML object model, per se. It's not really annotating or labeling the existing elements, except at a syntactic level.

Semantically, there's no difference between the following three snippets at the microdata level:

   <div itemscope>
    <p>Hello <span itemprop=a>b</span></p>
   </div>

   <p>Hello b</p>
   <!-- lots of intervening content -->
   <div itemscope><meta itemprop=a content=b></div>

   Bla <span itemscope><span itemprop=a>b</span></span>la bla

The HTML semantics of these three snippets are radically different, but at the microdata level, the content is the same.


> If i have only @title for expansions, of course I must insert acronym
> expansion elsewhere for microdata, thus writing it twice.

Yeah, if you want the expansion in the microdata model, and you want to use <abbr title> for the expansion, then that is true. But these are somewhat artificial constraints. You don't necessarily need or want the expansion in the microdata model, and you don't have to use <abbr title> for expansions (indeed it might even be better not to, as we discussed on a separate bug).


> Test my example, mouse over WHATWG and see if you can read the title on the
> link. If @value created a different type of widget (maybe focus widget
> instead of hover), the two wouldn't overlap and would be both visible.

Sure. This seems unrelated to microdata though. If you want this considered separately, please file a separate bug.


> > > Fourth, no information at all about
> > > expansion/explanation can be provided to non-visual UA users.
> > 
> > What's that got to do with microdata? I don't follow.
> 
> Nothing. From the beginning I said that inserting a new @value for this
> would address multiple issues. This refers to the fact that I'm not sure
> whether screen reader access @title. But <abbr@title> and <dfn@title> are
> important. Their content could be expressed as @value instead, and read as a
> new feature by AT.

Please file separate bugs for different issues, even if you think they would have the same solution.

As far as screen readers go, if they don't read title="", I don't see why they would read value="".


> > Actually it's exactly as semantic. The HTML markup semantic is the same
> > (modulo the addition of a "defining term" in the second one, but that seems
> > bogus semantically), and the microdata data model is identical. There is
> > nothing more machine-readable about the second than the first.
> 
> No it isn't, because the explanation is not connected to the part of content
> it aims to explain!!!

Not sure what you are disagreeing with here, if anything.


> > > Microdata adds attributes which define meaning, to existing elements.
> > 
> > Not necessarily existing elements.
> 
> There is RDF for new elements. The positive of Microdata, its step forward
> compared to RDF, is to add meaning to existing content.

RDF and microdata have quite different data models. They're not really related except in the same way that HTML and DocBook are related. (RDF, and its syntaxes like RDFa, are hugely complicated compared to microdata.)


> You yourself in a
> previous answer told me that the positive of Microdata is that it is built
> to work in parallel with HTML. And now for a so simple issue an author
> should add external elements? Can't it be done differently?

I don't really understand the problem here. Sure, there are times where the information you want to put in the microdata model is not somewhere you can easily get to with microdata. But that will always be true. Consider for example:

   <a href="/images/cat.jpeg">Cat</a>

What if you want the word "Cat" in in the microdata model? You need to add an element to do this (e.g. a <span> inside or outside the link).
What if you want "cat.jpeg" to be in the microdata model? You can't do that at all without replicating some data and adding elements.
What if you want "FELINE" to be in the microdata model? That text doesn't even appear in the HTML.

There's lots of cases like this.

The value of microdata is that it is really simple to use, and has simple solutions for problems like the above: you just add a <meta> element when you can't easily reuse the data from the DOM.

Sure, we could design something that solved every problem. But it would be so complicated that it would have no value over other mechanisms for representing machine-readable data.


> @title cannot be reached. @value could.

I don't understand why you think value="" could be reached but title="" could not. As far as I can tell they're just different ways of spelling the same thing. The problem with title="" isn't that it's spelt t-i-t-l-e, it's that it's an attribute, and the microdata model is carefully designed so that you always get data from exactly one source for each element, if the itemscope="" attribute isn't present.

We could certainly introduce more complicated features, like itemgetvaluefrom="title", or itemvalue="href attribute, pattern /([a-z]+.jpg)/", or whatever. But that would mean microdata loses its most valuable feature: simplicity.

I see. I thought that the problem with microdata and the acronym expansion were in the fact that @title is *this* relevant only in some elements, and so Microdata does not care recognizing the content of a global attribute in a small series of special cases, so it would be useful to add a somehow special attribute for this case.
I'll close this bug, because I see there are no real arguments to discuss for the Microdata issue. Later, if you figure out that @value can be useful for the other purposes (AT, tooltip overlap) AND you can also use it for Microdata, I hope you'll remember that I was the one who made so much noise about that. :)