I know that the inclusion of <data> element comes after a long brainstorming, I read some of the introductory articles online and I really appreciate it for conveying information like phone numbers, scientific/money data (which can be written in different valid ways depending on countries, as well as in a commonly readable fashion). And I think it can be late for changes. But if it were possible I would suggest changing the @value attribute with a @content attribute, for 2 reasons.
 - <data> itself conveys some information, but it should be accompanied by an attribute which defines the kind of information represented (which isn't necessary for <time>, of course, as it is dedicated to time-related data). The easiest way to convey such a meaning, in my opinion, is the use of Microdata or RDFa, together with a specific vocabulary (e.g. Schema.org). Both systems are ready to recognize @content, and data distillers based on Microdata and RDFa would both recognize the correct property value as the @content attribute value, rather than the text content of the element. @content should replace @value as the mandatory attribute, authors wouldn't have to specify it twice (now validators correctly report errors if @value is absent).
 - For a secondary reason, @content is more suitable than @value to represent metadata content, as it is the attribute of <meta> tags, while @value semantically reminds of <input> elements and has a totally different meaning.

As always I apologize for concentrating on minor features, mine is only a front-end developer's point of view.

> - <data> itself conveys some information, but it should be accompanied by
> an attribute which defines the kind of information represented (which isn't
> necessary for <time>, of course, as it is dedicated to time-related data).
> The easiest way to convey such a meaning, in my opinion, is the use of
> Microdata or RDFa, together with a specific vocabulary (e.g. Schema.org).
> Both systems are ready to recognize @content, and data distillers based on
> Microdata and RDFa would both recognize the correct property value as the
> @content attribute value, rather than the text content of the element.
> @content should replace @value as the mandatory attribute, authors wouldn't
> have to specify it twice (now validators correctly report errors if @value
> is absent).

I dunno about RDFa, I'd recommend against using it in general for a wide variety of reasons, but as far as microdata goes, <data> is designed specifically to work with its value="" attribute. There's no magic content="" attribute processing in microdata. Microdata uses HTML's semantics directly.


>  - For a secondary reason, @content is more suitable than @value to
> represent metadata content, as it is the attribute of <meta> tags, while
> @value semantically reminds of <input> elements and has a totally different
> meaning.

I don't understand. What's the difference in meaning?

The reason we didn't use content="" is that the "content" of an element is its children nodes, which comes between its tags in the markup:

   <element attributes="attribute values"> content </element>

The <meta> element can get away with having a content="" attribute because it's empty, so there's no content to confuse it with. Using content="" on elements with real contents is poor language design, though, IMHO.

(In reply to Ian 'Hixie' Hickson from comment #2)
> The <meta> element can get away with having a content="" attribute because
> it's empty, so there's no content to confuse it with. Using content="" on
> elements with real contents is poor language design, though, IMHO.

hmm, yeah, until reading this it really hadn't hit me that RDFa allows a "content" attribute *everywhere*, on any element, and how much of a really bad idea that is. What a mess.

(In reply to Ian 'Hixie' Hickson from comment #2)
> I dunno about RDFa, I'd recommend against using it in general for a wide variety of reasons, but as far as microdata goes, <data> is designed specifically to work with its value="" attribute. There's no magic content="" attribute processing in microdata. Microdata uses HTML's semantics directly.

Some authors don't follow this recommendation. Some of them even use the compact version of RDFa (I mean RDFa Lite 1.1, a good choice for many aspects: http://manu.sporny.org/2012/mythical-differences/). RDFa is a good trade-off between complexity (easier than Microdata for some reasons) and completeness. The fact is, in RDFa @content HAS a definite meaning. While RDFa Lite, though not implementing the full attribute set of Core, recognizes @content in <meta> elements, while it does not the same with @value (not even in <meter>). Must we make life difficult for those who want to implement it? If it became semantically defined in <data>, Microdata could use it as well.

(In reply to Michael[tm] Smith from comment #3)
> RDFa allows a "content" attribute *everywhere*
It is a chaos indeed, because text content ends up being useless for RDFa. But, as is, RDFa can't understand anything else. What if we allowed @content in a way to convince authors use <data@content> instead of <anytagIwant@content> (including <data@value@content> which is really ridiculous)? Something like "Wanna use @content? Wanna be a tidy author? Buy <data>!"

> The reason we didn't use content="" is that the "content" of an element is its children nodes, which comes between its tags in the markup

@value is not meant to represent the content of the element, of course, but indeed it seems meant to substitute (not describe) a content where it cannot be defined (empty elements) or where the content itself is not relevant for elements (<meter>):
 - it is the main attribute of "input" elements, which are empty, and it constitutes their content (in fact it is not defined for <textarea>, which has a content on its own); compared to this case, @value would cause the same confusion than @content;
 - it is present in <meter> and <progress> elements. These elements are meant to be represented graphically thanks to their attribute set, which do not describe an internal content. The latter is "a textual representation of the gauge's state in the element's contents, for users of (legacy) user agents that do not support the [...] element".
What comes out from all these things? A new author learning HTML5 from the ground up understands that @value is necessary in elements whose markup gives ALL the information (maybe graphically conveyed instead of textually), and the text content is more or less useless. The only case where @value has a similar meaning than in <data> is <option> (an <option> can have text for human users while being accompanied by a @value for the submission), but then again, @value and text content are exchangeable, as in absence of @value, the submitted value is the content. @value and textContent are related, in the sense the latter represents the readable meaning of the former, but in a different way - @value is meant for internal processing and not for standard values representation.

> Using content="" on elements with real contents is poor language design, though, IMHO.
Perhaps I'm wrong, but in this case I would say that "content" is a suitable name for an attribute which really describes the content of the element, rather than letting authors rely on the wrong thought that <data> will build a "magic" gauge/graph/visual representation of any sort.

I know that changes cost some work and I am not active part in that work. But here it seems worth.

> Some authors don't follow this recommendation. Some of them even use the
> compact version of RDFa (I mean RDFa Lite 1.1, a good choice for many
> aspects: http://manu.sporny.org/2012/mythical-differences/).

I do not think we should optimise HTML for authors who use RDF and RDF-derived technologies like RDFa.


> > The reason we didn't use content="" is that the "content" of an element
> > is its children nodes, which comes between its tags in the markup
> 
> @value is not meant to represent the content of the element, of course

Right. That's why <data>'s primary attribute should not be called "content".


> indeed it seems meant to substitute (not describe) a content where it cannot
> be defined (empty elements) or where the content itself is not relevant for
> elements (<meter>)

Right. This exactly describes the situation with <data>. The primary attribute is (for machines) the substitute for the actual element contents.


>  - it is the main attribute of "input" elements, which are empty, and it
> constitutes their content (in fact it is not defined for <textarea>, which
> has a content on its own); compared to this case, @value would cause the
> same confusion than @content;

I wouldn't say it describes their "contents". <textarea> in particular is educational here: it has contents, those are mapped to "defaultValue". Editing the "value" doesn't affect the element's contents. Resetting the element replaces its "value" by the elements contents (aka "defaultValue").

Indeed <textarea>'s "defaultValue" is defined in terms of the element's "textContent" attribute, which is itself defined as being a serialisation of the text in the element's contents (descendant Text nodes).


>  - it is present in <meter> and <progress> elements. These elements are
> meant to be represented graphically thanks to their attribute set, which do
> not describe an internal content.

<meter> and <progress> are supposed to have as contents equivalents for legacy user agents of the values describes in the attributes, as in:

   <meter min=0 max=5 value=3>3/5</meter>

Again, the contents and value of the element are distinct, as with <data>.


> What comes out from all these things? A new author learning HTML5 from the
> ground up understands that @value is necessary in elements whose markup
> gives ALL the information (maybe graphically conveyed instead of textually),
> and the text content is more or less useless.

Not at all.

   <button name="" value="">contents</button>
   the value="" is the submitted value, the contents are displayed

   <data value="">contents</data>
   the value="" is the machine readable value, the contents are displayed

   <option value="">contents
   the value="" is the submitted value, the contents are displayed

   <input value="">
   the value="" is the default value, user editable text is displayed

   <li value="">
   the value="" is the numeric value, the contents are displayed

   <meter value="">
   the value="" is displayed, the contents are for legacy UAs

   <progress value="">
   the value="" is displayed, the contents are for legacy UAs

   <param value="">
   the value="" is passed to the plugin, nothing is displayed

   <meta content="">
   the content is the value, nothing is displayed

<data> is very consistent with the other elements here. Only <meta> has content="". <meter> and <progress> are arguably the odd ones out.


> Perhaps I'm wrong, but in this case I would say that "content" is a suitable
> name for an attribute which really describes the content of the element

The content of the element is the bit between the start and end tags, not something in an attribute.

Marking WONTFIX per comment 5, since there was no follow-up; feel free to reopen the bug if I missed something.