Is there any indication of interest on the part of the Microformat community to change Microformats to use HTML features that weren't in HTML 4.01? That is, does case C boil down to just Microdata?

As a member of the microformats community I do use <time> for this in my hAtom.

If it's going to be made more generic might I suggest a new global attribute instead of a new tag?  That way we can use it in these cases:

<a machineval="2010-01-01" href="...">2 minutes ago</a>

<dd machineval="2010-01-01">Wednesday</dd>

etc

I'd rather not do a generic attribute because we saw when we were doing microdata's usability studies that that kind of pattern confuses authors. (It's one of the things RDFa does that confuses less advanced authors.) But there's no reason you couldn't use <data> in your examples:

   <a href="..."><data machineval="2010-01-01">2 minutes ago</data></a>

   <dd><data machineval="2010-01-01">Wednesday</data></dd>

(Probably with a different attribute name.)

Sure, you *can* use an extra tag in the example.  It's just very verbose and ugly :)

I think that changing it to <data> could make it too generic.

If anything, changing it to <datetime> would make more sense since it can currently contain either.

What other stuff outside dates and times are you referring to, out of interest?

(In reply to comment #5)
> I think that changing it to <data> could make it too generic.

As a publisher (front-end developer who builds sites for large companies) I would like to second Ian. Prior to HTML5, we were using hAtom to mark up articles and blog posts. When we were using hAtom, I heard frequent questions from other developers here regarding the way dates were marked up. The abbr, title and value-title patterns were confusing to developers that hadn't read the spec.

We have not had that problem with <article> + <time>. When training devs here on HTML5, folks immediately "got" what <time> was for. Also, having datetime be validate-able has meant it gets fixed if it's not properly formatted.

As a developer, I'm really against this change. Firstly, I'm already using and used to this element. And secondly, 'time' says much more information than 'data'. + Opera already implemented time element and I would be really angry on their place If would I have to change the implementation so soon.

(In reply to comment #0)
> There are several use cases for <time>:
> Use cases A and B do not seem to have much traction.

I doubt any of HTML5 elements have much traction. 

> Use case C applies to more than just dates, and the lack of solution for stuff
> outside dates and times is being problematic to many communities.

I can imagine a use case for phone numbers, and address.  My view is expanding the scope of the <time>/<data> element is a slippery slope. Of all elements in HTML5, time is the one that is least ambiguous. 

> Proposal: we dump use cases A and B, and pivot <time> on use case C, changing
> it to <data> and making it like the <abbr> for machine-readable data, primarily
> for use by Microformats and HTML's microdata feature.

How would this look like?

> If anything, changing it to <datetime> would make more sense since it can
> currently contain either.

Agreeing that <data> is too generic. I think <time> or <datetime> makes the most semantic sense, and <time> is indeed implemented in at least one browser.

(In reply to comment #3)
>    <dd><data machineval="2010-01-01">Wednesday</data></dd>

For case C, how is this better than
<dd><meta content="2010-01-01" itemprop='...'>Wednesday</dd>
?

That is, if you throw away the string "Wednesday" for Microdata processing anyway, what's the use of the end tag?

Opera has already implemented and shipped support for <time>, so we're not ecstatic about throwing it away again.

As Henri hints at, the only difference between <data> and <meta> here would be that with data the content being overridden would be explicit. Yet, that isn't part of the Microdata model, so why would it be better? Aesthetics?

While I like the concept of a generic data element, I feel like this would be confusing given how many other things use the term "data" in html5. There's already a lot of confusion between microdata and data-* attributes + we have "datablock" script tags. Also, in all these other cases, the data is not only non-displayed but non-display-able w/o machine interpretation.

But perhaps instead of a generic data-tag we should be thinking about more particular data-tags, such as <integer>, <number>, <url>, etc. Or perhaps we could allow the @type attribute to be used on <span> elements to markup data-types.

After some discussion and thought, I've changed my mind and decided I like the <time> tag, though I would not be fully opposed to <datetime>

I had thought that I was against that because it smelled like another img/video/audio/object debacle, but I've realised since that unlike img/video/audio, time actually provides additional and very useful semantics over just "data"

The problem with keeping <time> is that there's a bunch of similar cases that we're not handling at all currently (other than with <meta>) that are essentially identical but aren't <time>s:

 - dimensionless numbers (2.3)
 - numbers with units (5kg)
 - enumerated values, like months (February) or days of the week (Monday)

...etc. A new element for each of these is rather messy.

For some reason, many people are really not liking the <meta> solution. I don't know why. (I often get people asking me how to mark up a number in microdata and when I say <meta> they seem unhappy.)

Assuming that this is only for microdata, what reasons do we have to think that <data itemprop=country machineval=se>Sweden</data> is less confusing than <span itemprop=country itemval=se>Sweden</span>? It seems like the former would be harder to massage into existing markup if there's already a suitable element wrapping "Sweden", which will often be the case. It's also a lot less obvious how it affects microdata just from looking at it.

AFAICT, none of the variants in http://blog.whatwg.org/usability-testing-html5 tried to use attributes for overriding the content, I take it you're extrapolating from something else?

(It would be quite nice to not use <meta> for microdata. The initial reaction is bound to be "WTF?" and you can't style the visible content based on it since it's a void element.)

Another datatype people want to mark up a lot are durations (number and unit, but the number is in a special form) and time ranges (two times).

After https://plus.google.com/105458233028934590147/posts/Tmh8uzpGM9j I would actually agree that itemval is a bad idea, in particular because of the confusing nature of something like <img src=foo itemprop=img itemval=bar>. It would also make itemValue reflection a bit funky, you'd really have to look at the definition in order to understand which attribute it maps to.

As for the use cases:

 - pubdate can be relegated to data-pubdate for the <10 people in the world who want to export HTML to Atom.

 - HTMLTimeElement.valueAsDate isn't very useful anyway.

 - Has the microformat community expressed any interest in moving away from HTML4?

If microdata is the only serious use case, then machineval="" seems a poor attribute name. <data value="se">Sweden</data> is better IMO, mirroring <option value="se">Sweden</option>. There's no reason to allow <data>Sweden</data> at all, so itemValue could always reflect the value attribute, as opposed to HTMLTimeElement.itemValue which behaves either as .dateTime or .textContent.

(Note that Opera is still "not ecstatic" about dropping <time>, I'm just trying to see the alternatives.)

On a tangential note, with this change it might make sense to go back to only allowing <meta> and <link> in <head>. <link itemprop> for hidden URLs in the markup would be collateral damage there, but <a itemprop></a> would continue to fill that purpose.

<time> *does* express something more useful than just <data> or <meta> in that it tells the UA that its contents are a datetime.  <data> would just tell the UA "there is something here" and would be semantically equivalent to <span>

Thus, I support keeping <time> for the extra semantics
But could be convinced that an extra global attr is a good idea

Yet another meaningless tag makes no sense.

(In reply to comment #19)
> <time> *does* express something more useful than just <data> or <meta> in that
> it tells the UA that its contents are a datetime.

UA's don't actually make any use of this fact, though. It does allow validators to report errors in the date/time syntax, but with vocabulary-specific validation this would still be possible, see e.g. http://bugzilla.validator.nu/show_bug.cgi?id=851

http://people.opera.com/philipj/time.html

By this test, only Opera supports <time>. Other tested browsers were IE 10.0.1008.16421, Firefox 5.0 and Chromium 12.0.742.112.

(Not an argument either way, just reporting my findings.)

"Uas don't currently use the semantics" isn't a very good argument against the usefulness of the semantics, especially in something as new and fluid as HTML5.

So what is it useful for, other than validation?

Correction: Opera doesn't have an official position, if we do Anne van Kesteren will say so.

I'm definitely leaning towards doing this. The alternative seems to be to have a whole slew of elements for this kind of thing:

   <time datetime="2010-10-10">
   <number value=10>
   <scalar value=10 unit=kg>
   <duration value="1h10m2.2s">
   <timerange start="2010-01-01" end="2010-02-02">
   <enum value="spring">

...all of which pretty much do exactly the same thing: nothing.

(In reply to comment #25)
> I'm definitely leaning towards doing this. The alternative seems to be to have
> a whole slew of elements for this kind of thing:
> 
>    <time datetime="2010-10-10">
>    <number value=10>
>    <scalar value=10 unit=kg>
>    <duration value="1h10m2.2s">
>    <timerange start="2010-01-01" end="2010-02-02">
>    <enum value="spring">
> 
> ...all of which pretty much do exactly the same thing: nothing.

Nothing except the one thing that matters: adding semantic value.

If you don't care about the semantic value I would definitely say that an attribute solves the "some sort of machine data here" use case much better.

I don't see how you can be against the extra semantic data here when the argument was the same (though much weaker, IMHO) for adding seperate <video> and <audio> instead of just adding JS APIs to <object type="video/*">

Adding the JS API to <video> and <audio> was for practical authoring reasons: overloading <object> would result in a far more buggy, more complicated API. It had nothing to do with semantics.

Semantics on its own is not a use case.

(In reply to comment #25 from Hixie)
> I'm definitely leaning towards doing this. The alternative seems to be to have
> a whole slew of elements for this kind of thing:
> 
>    <time datetime="2010-10-10">
>    <number value=10>
>    <scalar value=10 unit=kg>
>    <duration value="1h10m2.2s">
>    <timerange start="2010-01-01" end="2010-02-02">
>    <enum value="spring">

If that's a complete list, that's not really much of a slew. It's six elements whose purposes are very clear from their name, versus one new element whose name does very little to make its purpose clear. And even if the above is not a complete list, I think the list of new elements to consider is still finite and would not be much larger than what you have above.

> ...all of which pretty much do exactly the same thing: nothing.

If the expectation is that UAs would not ever be doing anything either with any of the elements suggested in that list or with the proposed <data> element, then I guess it matters a lot less which ends up being added.

But as far as elements that UAs are actually expected to do something with, I think that experience with the <input> element has shown that adding a generic element with an attribute for subtyping it into multiple subtypes (now more than a dozen) brings a number of hidden costs and complications. The subtyping essentially makes it into multiple logical abstract "elements" anyway, and the subtyping-by-attribute mechanism just makes it look like there's less complexity around it than there actually is.

I think subtyping in that way is a serious design mistake and an anti-pattern that should not be perpetuated further -- even for an element that does nothing in UAs. We'd be better off in the long run adding nothing at all than we would be adding something like that.

(In reply to comment #25)
> I'm definitely leaning towards doing this. The alternative seems to be to have
> a whole slew of elements for this kind of thing:
> 
>    <time datetime="2010-10-10">
>    <number value=10>
>    <scalar value=10 unit=kg>
>    <duration value="1h10m2.2s">
>    <timerange start="2010-01-01" end="2010-02-02">
>    <enum value="spring">

I'd be interested in hearing how you would model a time range with the proposed <data> element.

Something like <date type=timerange start=2010-01-01 end=2010-02-02> ?

(In reply to comment #25)
> I'm definitely leaning towards doing this. The alternative seems to be to have
> a whole slew of elements for this kind of thing:
> 
>    <time datetime="2010-10-10">
>    <number value=10>
>    <scalar value=10 unit=kg>
>    <duration value="1h10m2.2s">
>    <timerange start="2010-01-01" end="2010-02-02">
>    <enum value="spring">
> 
> ...all of which pretty much do exactly the same thing: nothing.

as a non-exhaustive set of examples they revel the implications of including such fine-grained tags. if these elements are included the same reasoning would be unable to exclude the entire raft of other elementary data types.

any specification of these as distinct elements would have to content with a large overlap in common features, yet diverging implementation. this leads to problems such a requiring a <timerange> element to represent ranges in time, yet which is unable to represent generic ranges, of numbers, scalars, even durations.

i believe a more generic solution, such as <data> is required in order to have a solution which is capable of representing every value without requiring every data type to be discovered, specified and implemented.

in short, i think <time> and its relatives represent a non-scalable solution for a specification and does not leverage the ability for authoring creativity and innovation to drive the web forward.

(In reply to comment #26)
> (In reply to comment #25)
> > I'm definitely leaning towards doing this. The alternative seems to be to have
> > a whole slew of elements for this kind of thing:
> > 
> >    <time datetime="2010-10-10">
> >    <number value=10>
> >    <scalar value=10 unit=kg>
> >    <duration value="1h10m2.2s">
> >    <timerange start="2010-01-01" end="2010-02-02">
> >    <enum value="spring">
> > 
> > ...all of which pretty much do exactly the same thing: nothing.
> 
> Nothing except the one thing that matters: adding semantic value.

but how much semantic value is there in knowing that there is a time, duration or a weight measurement on a page? what value does this have if the relation of what it refers to is not known? 

these elements represent a bloated way of marking up a limited and inflexible set of units and without any real practical purpose for the author or the consumer. 

what is the purpose of <time> markup anyway? a UA won't be able to provide any additional interfacing over such primitive datatypes. a resource consumer will face the same problem of context, it might be able to find all data values on a page but in isolation they are almost useless, and when distinguishable from regular text anyway like dates, times and SI values are anyway, there would seem to be little incentive for their markup anyway.

given the parsability of the text representations of these data values, and the requirement of effort and overhead for authors to provide this information, it might be more prudent to allow <data> to provide disambiguation instead of declaration. 

in this way, a text value of "5kg" would not require any additional effort for an author to declare, is backward compatible with all current documents, and yet when marked-up using <data> would allow for pedantic authors to define unambiguously that the 5kgs they refer to only applied at san jose during the 4th full moon of 2011 in the gregorian calendar, as gravitational force is bound in space over time. 

a solution which fails to allow for complete unambiguous declaration is not a solution for data.

(In reply to comment #28)
> But as far as elements that UAs are actually expected to do something with, I
> think that experience with the <input> element has shown that adding a generic
> element with an attribute for subtyping it into multiple subtypes (now more
> than a dozen) brings a number of hidden costs and complications. The subtyping
> essentially makes it into multiple logical abstract "elements" anyway, and the
> subtyping-by-attribute mechanism just makes it look like there's less
> complexity around it than there actually is.

It's true that there is a lot of complexity in <input> elements, and possibly some of them shouldn't be subtypes especially when viewed in conjunction with new form elements which are not input subtypes.

However, there is a great deal of overlap through all input elements and if there is hidden complexity this also implies that there is a great deal of abstraction and are incredibly powerful elements. that the complexity is hidden just results in an interface which is easier to learn and use. 


> I think subtyping in that way is a serious design mistake and an anti-pattern
> that should not be perpetuated further -- even for an element that does nothing in UAs. We'd be better off in the long run adding nothing at all than we would
> be adding something like that.

i disagree and on the contrary i think that subtyping is probably the most prudent mechanism for expanding the functionality of HTML without limiting it genericity or incurring duplication.

(In reply to comment #29)
> I'd be interested in hearing how you would model a time range with the proposed
> <data> element.
> 
> Something like <date type=timerange start=2010-01-01 end=2010-02-02> ?

It is possible to declare a time intervals in ISO 8601, eg:

<data value="2007-03-01T13:00:00Z/2008-05-11T15:30:00Z">label</data>

(In reply to comment #31)
> (In reply to comment #26)
> > Nothing except the one thing that matters: adding semantic value.
> 
> what is the purpose of <time> markup anyway? a UA won't be able to provide any
> additional interfacing over such primitive datatypes.

False.  I spent some time working at a company (MashLogic) trying to find ways of identifying times, weights, currency figures, and similar on pages.  Why?  So that we could present the values to the user in their preferred format.  See times in their local timezone, weights in their preferred system, etc.

That's one reason why we originally added <time>, but it never seemed to get much author interest. We got more questions about how to avoid it than how to use it, if anything.

I don't think the list I gave above is comprehensive. It's just what I could come up with in about 5 minutes off the top of my head.

There are costs to many elements also. The microdata algorithms, for instance, would have to special-case them all. Validators would have to know all the various ways they can be used. There's the documentation, testing, and tutorial cost.

I don't think the analogy to <input> works here, because this element would be non-interactive and wouldn't have multiple modes: it would just be one feature that could be used for many things. It's like how class="" can be used for many different things, but it's still just one feature.

Exactly what format you would use for various data types would depend on the vocabulary. For example if you had a data field that had to express a date range with error bars it could be:

   <data value="2010-03-12±4 ..  2011-01-05±3">

...or it could be:

   <data value="2010-03-08:2010-03-16 2011-01-02:2011-01-08">

It's really up to the author. And note that this data format wouldn't be possible with any of the elements I listed, so we'd have to add yet another one to the list...

Is there any data showing how people actually use <time> in practice? i.e. is it actually giving anyone any of its hypothetical benefits?

(In reply to comment #36)
> Is there any data showing how people actually use <time> in practice? i.e. is
> it actually giving anyone any of its hypothetical benefits?

Isn't it a bit early to get that data?

Sorry, I meant <time>-equivalents, such as those referenced in comment 34.

(In reply to comment #25)
> I'm definitely leaning towards doing this. The alternative seems to be to have
> a whole slew of elements for this kind of thing:
> 
>    <time datetime="2010-10-10">
>    <number value=10>
>    <scalar value=10 unit=kg>
>    <duration value="1h10m2.2s">
>    <timerange start="2010-01-01" end="2010-02-02">
>    <enum value="spring">
> 
> ...all of which pretty much do exactly the same thing: nothing.

My immediate thought was that <data> would have to take different attributes - which could even be empty/boolean-ish, and which would be used depending on the kind of data:

<data datetime="2010-10-10">10th of October</data>
<data datetime="">10th of October</data>
<data scalar=10 unit=kg>

Or, eventually - in case of a generic @value attribute - some kind of kind/type attribute to indicate the kind of data:

<data kind=time value="2010-10-10">10th of October</data>

The only trouble I see is that we are then approaching <object> - in a literal/syntactic way:

<object type=time data="2010-10-10">10th of October</object>

And since object@data takes URLs, perhasp time as a URI is also a thought:
   http://www.annodex.net/TR/draft-pfeiffer-temporal-fragments-03.html
  http://placetime.com/instant/gregorian/

Was differentiated attributes part of your thinking behind <data>, Mr Editor?

(In reply to comment #38)
> Sorry, I meant <time>-equivalents, such as those referenced in comment 34.

* twitter.com

<span data-long-form="true" data-time="1318428815000" class="_timestamp">6 minutes ago</span>

* weibo.com

<strong date="1318425833">(Chinese) 2 minutes ago</strong>


I think these sites use these markups as anchors for places to be updated as time goes. Not sure if this is closer to use case A. or C., but this seems like a CSS + Component Model thing if I understand the latter correctly.

(In reply to comment #39)
> 
> My immediate thought was that <data> would have to take different attributes -
> which could even be empty/boolean-ish, and which would be used depending on the
> kind of data: [...]
> 
> Was differentiated attributes part of your thinking behind <data>, Mr Editor?

No, Mr Contributor. :-) Having multiple attributes would lead to confusing questions about precedence, would make it hard to integrate into processing models such as microdata, and would lead to a huge number of attributes as we kept coming up with new types. I don't see much value in doing that. One attribute would likely be sufficient.

(In reply to comment #40)
> 
> <span data-long-form="true" data-time="1318428815000" class="_timestamp">6
> minutes ago</span>
> 
> <strong date="1318425833">(Chinese) 2 minutes ago</strong>

Looks like a <data> element would handle these pretty well.

Dropping time is one of the most odd things I've ever heard as for HTML5 spec development. It's like dropping all semantic elements in favor of semanticless <div> and <span> elements. Completely pointless.

Power of semantics is exactly in having individual elements for particular purposes. This at all cannot be bad since this is what semantics itself is about.

I would humbly yet strongly recommend the editor to consider avoiding an initiatives like such harmful proposals as dropping particular semantic element in favor of something more abstract (and therefore _less_ semantic and useless).

Quite the contrary, it makes sense to add more date-related elements, such as <year> and <month>.

In general, there should be dedicated HTML element for _each_ _general_ class of things. This could make possible for robots to determine text sense more accurately and thus provide more relevant parsing results (search results in particular).

For example, for search query like "birth year of Some Man", search engine could prefer a year that is marked-up as <year> element instead of making _assumptions_ about whether a number (not marked-up as year) in an indexed text is a year or not.

<time> element should be kept intact. Only thing to probably do here is maybe rename verbose and too usecase-narrow 'datetime' attribute to more compact and universal 'value' attribute.

'value' attribute could be _consistently_ used in <time>, <year>, and <month> elements (as well as for other elements that are currently noninvented yet). For example:

<time value="2011-10-20">October 20, 2011</time>
<year value="2011">'11</year>
<month value="10">October</month>

By the way, I would personally prefer to use <date> element for dates that has no time part while still using <time> element for dates that contain time part. For example:

<date value="2011-10-20">October 20, 2011</date>

however:
<time value="2011-10-20T23:45:00Z">October 20, 2011, 23:45</time>

By the way too, it makes sense to simplify syntax of 'value' ('datetime' currently) attribute to be more simple and similar MySQL datetimes:

<time value="2011-10-20 23:45">October 20, 2011, 23:45</time>

Thanks.

(In reply to comment #42)

> In general, there should be dedicated HTML element for _each_ _general_ class
> of things. This could make possible for robots to determine text sense more
> accurately and thus provide more relevant parsing results (search results in
> particular).

In the case of the <a> element, we are able to use it for an unlimited amount of different kinds of URL schemes. It could be cool if we, in a similar fashion, could have a <data> element that was as flexiible as the <a> element is for links.

(In reply to comment #43)

You are free to introduce new elements. However besides, not instead of existing (more appropriate in certain situations) ones.

My main point is that if we have an element for an exact semantic purpose, then this element should be used in appropriate situations while more general element could be used for _rest of_ (not all) situations.

If we cannot express _any_ sense with existing structural elements, then this at all is not a reason to drop all existing semantics altogether.

There is no reasons to _replace_ <time> with <data> (this would be completely irrational). Instead, <data> could be an additional feature (if someone needs it) _not_ replacing existing (semantically more narrow and precise) <time> element, but covering _rest of_ situations instead.

(In reply to comment #41)
> (In reply to comment #40)
> > 
> > <span data-long-form="true" data-time="1318428815000" class="_timestamp">6
> > minutes ago</span>
> > 
> > <strong date="1318425833">(Chinese) 2 minutes ago</strong>
> 
> Looks like a <data> element would handle these pretty well.

Maybe. 

On the other hands, what are the uses cases for marking up dimensionless numbers, numbers with units or enumerated values. Are there existing HTML4-equivalnets?

Here are some potential examples that might benefit from <data>.

* weather.com[1]

Some of the temperatures are marked up as, say, <strong>56

The main use case for <data> is in cases involving microdata and microformats, where there is often a need to include a human-readable version of a computer-readable piece of data, be it a time, date, rating, etc.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, 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

Status: Accepted
Change Description: see diff given below
Rationale: See comment 0 for the basic rationale, and some of my other comments for details on particular decisions.

> Change Description: see diff given below
> Rationale: See comment 0 for the basic rationale, and some of my other comments
> for details on particular decisions.

The diff can be found here: http://html5.org/tools/web-apps-tracker?from=6782&to=6783

(In reply to comment #47)
> EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
> satisfied with this response, 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
> 
> Status: Accepted
> Change Description: see diff given below
> Rationale: See comment 0 for the basic rationale, and some of my other comments
> for details on particular decisions.

(In reply to comment #47)
> EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
> satisfied with this response, 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
> 
> Status: Accepted
> Change Description: see diff given below
> Rationale: See comment 0 for the basic rationale, and some of my other comments
> for details on particular decisions.

Removing a element with semantics and replacing it with what basically is a clone of the span element is a step in the wrong direction. 

A way to provide machine readable version of the data is already handled by RDFa without any new elements. Why not try to work together with them to try to find a generic mechanism to do this that works for both formats?

In addtion to that, schema.org examples have no business in the W3C spec because microdata is not part of HTML5 ( just like RDFa isn't part of the spec ).

(In reply to comment #47)
> Status: Accepted
> Change Description: see diff given below
> Rationale: See comment 0 for the basic rationale, and some of my other comments
> for details on particular decisions.

Self-contained decision detached from reality and harming HTML5 semantics itself. Shocked.

It's probably <time> to replace spec editor. Sorry.

http://foolip.org/microdatajs/live/ has been updated to reflect this change if anyone wants to see <data> in action.

So we create a <time> element that is used to markup times in a document, decide that it is to specific and replace is with a <data>element that can only be used to mark up time? this doesn't make much sense. Its much less semantic and will lead to confusion with the data-* attribute.

There is also a fourth use case where you could easily access all <time> elements from javascript to transform them e.g. to human relative time while keeping a machine readable time in the datetime attribute.

Why not just add a generic data attribute. Why take away something that is actively being used?

This leaves me confused. Our mission is to create the semantic web. And then we do the opposite. Totally agree with Patrick and Marat.

I just heard about this issue upon reading it at .NET magazine (http://www.netmagazine.com/node/1517).

Frankly, I'm completely shocked that such a discussion would even arise. And then on top of that seeing that the vast majority of the posts here are definitely against such a change. Yet Hickson stands his ground despite what the community is saying. I thought this was essentially a "community" effort, was it not?

I am a relatively inexperienced developer compared to many of the people who have posted their views on this issue here, so at least *listen* to what others here are saying!

I counted at least 23 posts that were overtly for keeping the <time> element and only 5 that specifically mentioned being for dropping it for the <data> element (minus Ian's posts).

(In reply to comment #36)
> Is there any data showing how people actually use <time> in practice? i.e. is
> it actually giving anyone any of its hypothetical benefits?

tl;dr: It's useful to show shortened or "friendly" versions of full timestamps. I would suggest either reverting this change, or adding a type attribute to fully replicate the time element.

(Note: I am speaking personally in this comment and not in any official capacity on behalf of my employer)

I can't offer broad data but I can say we've implemented the <time> element in production versions of several Atlassian products (Confluence, JIRA, Bamboo, BitBucket). It never occurred to me at least that such a useful element would get removed from the spec.

The most common use case is retaining full timestamps in the DOM while still providing shortened, localised or "friendly" times ("5 minutes ago"), eg:

<time datetime="2011-11-02T16:23:30+11:00">7 hours ago</time>

We've used this pattern on wiki editing diff pages, BitBucket change history pages, build activity screens, etc.

The data element as proposed seems to lack the disambiguation of the time element... to achieve the same result we would have to add more markup, eg. in the form of microdata, or simply hope all data elements in the document happen to be a time. Since we have products working with user-generated content and an ecosystem of plugin developers, relying on such a broad convention would be poorly advised.

So by this change we effectively lose the ability to simply, unambiguously mark up a time or date with a single element. We either add attributes to wrapper elements, or we rely on a weak convention of not using data for anything other than time - which suggests it should just stay <time> in the first place.

I wouldn't object to the data element being *added* to the spec in addition to time, although I can't really see much use for it without some form of type attribute to allow different uses to coexist, eg:

<data type="datetime" value="2011-11-02T16:23:30+11:00">7 hours ago</data>

However to my mind time is such a common use case it seems appropriate to retain the specific element.

Ben, can you elaborate on what you actually *do* with the <time> element? Is it as a convenient styling hook, do you have scripts that operate on it, is it a convention for plugin developers to scrape dates from the markup (as opposed to giving them access to the backend representation), or something else? (I presume it is not just "retaining full timestamps in the DOM", since having a value in an attribute by itself doesn't do anything.)

(In reply to comment #56)
> Ben, can you elaborate on what you actually *do* with the <time> element? Is it
> ...

The same question applies to <data> as well, no?

Just to add to the "<time> being used in production" cases..

We at Readability have been recommending <time> as the element to use to best describe an article's publication date since February: http://www.readability.com/publishers/guidelines

I don't have any statistics on how many publishers have followed these guidelines, but it's certainly non-zero. 

I have other, more personal reasons to dislike this change (approachability of a generic <data> element to relatively new developers vs the very clear <time> element, etc), but on a logical level, I can say that it will make our job as a scraper a good deal harder in the future, particularly with the ambiguity of using class as the attribute to distinguish a data element. <time>, replete with the pubdate attribute, is as unambiguous as it gets.

To be fair, we deal with terrible markup on a daily basis, so we'll be handling all sorts of uninformed markup anyway. But the clarity found in <time> with pubdate is something that would be very nice to have.

(In reply to comment #57)
> (In reply to comment #56)
> > Ben, can you elaborate on what you actually *do* with the <time> element? Is it
> > ...
> 
> The same question applies to <data> as well, no?

It's for marking up a human-readable and a machine-readable representation of the same thing for use with microformats, microdata or similar. This is what I thought the point of <time> was as well, but it seems unlikely that this is what people are actually using it for, thus the question.

As anyone tried to assess how widely is the <time> element currently used in the wild? I was about to submit a web grep at http://blekko.com/webgrep but looks like Jeni already submitted one and it's been approved: http://blekko.com/webgrep?page=view&id=8638947e26c2cf16e32d3487fc187ac5. So let's wait and see the results.

(In reply to comment #59)

> It's for marking up a human-readable and a machine-readable representation of
> the same thing for use with microformats, microdata or similar. This is what I
> thought the point of <time> was as well, but it seems unlikely that this is
> what people are actually using it for, thus the question.

<time> element is _easy_ way to _add semantic sense_ to text without diving into verbose unusable microformat garbage oriented to narrow usecases.

Markup (HTML) should never be confused with pseudo-markup (microformats).

Pseudo-markup should be _supplement_ to true markup, not replacement for it. Otherwise, all semantic elements (H1, P, UL, etc.) could be removed in favor of more "universal" DIV -- that would be complete semantic absurd.

(In reply to comment #61)

> <time> element is _easy_ way to _add semantic sense_ to text without diving
> into verbose unusable microformat garbage oriented to narrow usecases.

For reference, I've uploaded a copy of the section on <time> as it was to http://people.opera.com/philipj/2011/10/28/the-time-element.html

It states that "This element is intended as a way to encode modern dates and times in a machine-readable way" and the first example is precisely about "verbose unusable microformat garbage". It sounds like people are using it for something else, in which case the spec should be fixed to reflect that if <time> is brought back.

(In reply to comment #62)
> For reference, I've uploaded a copy of the section on <time> as it was to
> http://people.opera.com/philipj/2011/10/28/the-time-element.html
> 
> It states that "This element is intended as a way to encode modern dates and
> times in a machine-readable way" and the first example is precisely about
> "verbose unusable microformat garbage". It sounds like people are using it for
> something else, in which case the spec should be fixed to reflect that if
> <time> is brought back.

Nice to have the actual text so it's possible to see how it was definied.

The time element could be used for creating a semantically rich web page. This could just be because that person thinks it is important to use the right elements to mark up the data (use elements that represent lists when the document contains lists and so on). It does not have to have anything to do with RDFa, microdata, or microformats. The data element cannot be used for this because it semantics for it is the same as the span element. It says that there is something here, but nothing about which type of data it is, just some data in a machine readable format with an unknown data type.

What could the time element be used for, one example could be for converting a date/time with a time zone specified to the local time zone. It has already been suggested by others that the time elements

(In reply to comment #62)
> (In reply to comment #61)
> 
> > <time> element is _easy_ way to _add semantic sense_ to text without diving
> > into verbose unusable microformat garbage oriented to narrow usecases.
> 
> For reference, I've uploaded a copy of the section on <time> as it was to
> http://people.opera.com/philipj/2011/10/28/the-time-element.html
> ...

Thanks.

Alternatively: <http://www.w3.org/TR/2011/WD-html5-20110525/text-level-semantics.html#the-time-element>

Posting a reminder that anytime anyone wants to check out the spec as it looked going into Last Call (May, 2011), a snapshot was made at that time and is posted on the front page of the HTML WG site. 

Example for time:

http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element

(In reply to comment #56)
> Ben, can you elaborate on what you actually *do* with the <time> element? Is it
> as a convenient styling hook, do you have scripts that operate on it, is it a
> convention for plugin developers to scrape dates from the markup (as opposed to
> giving them access to the backend representation), or something else? (I
> presume it is not just "retaining full timestamps in the DOM", since having a
> value in an attribute by itself doesn't do anything.)

Styling is not particularly the driver for using <time>; although it does give an efficient and convenient selector for style and scripting.

Note that I didn't personally implement time in all our products so I can't provide the full deep dive of details... however one specific use case reported is BitBucket uses jQuery.localize to convert UTC timestamps to localized equivalents. 

We anticipate plugin devs will make use of <time> but it's a bit too early to expect a swathe of usage - these things do take a while to settle in. <time> has not really been a stated or promoted convention, since semantic markup is basically self-explanatory to people who want to manipulate the DOM.

To expand the thought a bit, we do have a pure-DOM plugin system alongside our more deeply-integrated/backend plugin system. The DOM system is commonly used for greasemonkey-style customisation by users (hence why people would use the DOM and not access backend data directly).

We are in the process of converting our UI to HTML5 (doctype switch first) and <time> was a common early choice based on ease of implementation and solving a common problem (working with human- and machine-readable time information). I feel I should point out this use case should not be downplayed just because it sounds simple.  We used <time> because that's what it's for and we show a lot of times in our UI; and we want to have access to both the full timestamp and a human-readable version of that information.

Thanks Ben, I found an example of it at http://sandbox.onjira.com/browse/TST-1353

It looks like for giving plugins (scripts) access to the timestamps, <data class=date value="..."> would do the exact same thing, but if <time> exists then it is of course the better match.

(In reply to comment #62)
> (In reply to comment #61)
> 
> It states that "This element is intended as a way to encode modern dates and
> times in a machine-readable way" and the first example is precisely about
> "verbose unusable microformat garbage". It sounds like people are using it for
> something else, in which case the spec should be fixed to reflect that if
> <time> is brought back.

I don't see a problem with that spec. The way the element is being actually
used is much more like the examples at the bottom. The examples in the spec
aren't prioritised are they?

(In reply to comment #67)
> It looks like for giving plugins (scripts) access to the timestamps, <data
> class=date value="..."> would do the exact same thing, but if <time> exists
> then it is of course the better match.

You could also achieve the result with data- attributes, but both options rely on page-level convention instead of setting a standard. I think relying on a custom class or attribute is a retrograde step from having an element with universally defined semantics/purpose.

I can see the value of adding the data element as a workhorse for microformats; I just think <time> is a common enough use case that a single, dedicated element is the way to go. Much as I like microformats, I don't think we should need one just to mark up a timestamp :)

(In reply to comment #68)
> (In reply to comment #62)
> > (In reply to comment #61)
> > 
> > It states that "This element is intended as a way to encode modern dates and
> > times in a machine-readable way" and the first example is precisely about
> > "verbose unusable microformat garbage". It sounds like people are using it for
> > something else, in which case the spec should be fixed to reflect that if
> > <time> is brought back.
> 
> I don't see a problem with that spec. The way the element is being actually
> used is much more like the examples at the bottom. The examples in the spec
> aren't prioritised are they?

Of course not, I'm just pointing out that the main reasons that <time> exists are not the reasons that people are using it for. To elaborate:

1. No browser has implemented the CSS localization stuff. (I suggested dropping it in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024106.html but Hixie opted to keep it in http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-July/027289.html)

2. People are barfing at the idea of using microformats or microdata and saying that <data> is useless.

3. pubdate="" was added in http://html5.org/r/3116 specifically to enable the conversion to an Atom feed. However, I'm virtually certain that no one has ever used it for that purpose because (a) no one seems to have noticed or cared that the conversion algorithm was removed and (b) when I tried implementing that algorithm in January I found and filed the kinds of bugs that seem to indicate that no one had done it before.

If <time> belong in the spec then it should also match what people use it for. AFAICT, that is:

1. Script and styling hook, kind of like <header> or <aside>
2. Documentation purposes
3. Semantics as a goal in itself

Revert request is here:

http://lists.w3.org/Archives/Public/public-html/2011Nov/0011.html

At this point, we are looking to create one or more issues and soliciting proposals on each.  We are looking for suggested title and text for the tracker issue(s).

(In reply to comment #71)
> Revert request is here:
> 
> http://lists.w3.org/Archives/Public/public-html/2011Nov/0011.html
> 
> At this point, we are looking to create one or more issues and soliciting
> proposals on each.  We are looking for suggested title and text for the tracker
> issue(s).

(In reply to comment #71)
> Revert request is here:
> 
> http://lists.w3.org/Archives/Public/public-html/2011Nov/0011.html
> 
> At this point, we are looking to create one or more issues and soliciting
> proposals on each.  We are looking for suggested title and text for the tracker
> issue(s).

I added the TrackerRequest keyword so here are 2 issues I see along with suggested titles.

"Handling of machine-readable data in HTML5" - This issue would include adding a data element, if the time element should be kept or not (and how it could be improved if it is kept in the spec), if the pubdate attribute should be kept, and if microdata can share some element/attribute with RDFa relating to machine-readable data.

"Keeping HTML5 neutral about Microdata/RDFa" - Should the HTML5 specification contain things like schema.org microdata examples. And if that is OK should the spec also include RDFa examples of the same thing? Or maybe these examples should go in a separate document.

(In reply to comment #72)
> 
> I added the TrackerRequest keyword so here are 2 issues I see along with
> suggested titles.
> 
> "Handling of machine-readable data in HTML5" - This issue would include adding
> a data element, if the time element should be kept or not (and how it could be
> improved if it is kept in the spec), if the pubdate attribute should be kept,
> and if microdata can share some element/attribute with RDFa relating to
> machine-readable data.

Can that be split into smaller issues?
 
> "Keeping HTML5 neutral about Microdata/RDFa" - Should the HTML5 specification
> contain things like schema.org microdata examples. And if that is OK should the
> spec also include RDFa examples of the same thing? Or maybe these examples
> should go in a separate document.

Once the change is reverted, is that an issue that would apply to the document as it exists at that time?  See also the following decisions:

http://lists.w3.org/Archives/Public/public-html/2011Mar/0586.html
http://lists.w3.org/Archives/Public/public-html/2010Jan/att-0218/issue-76-decision.html

- Sam Ruby

(In reply to comment #73)
> Can that be split into smaller issues?

Yes, I guess most of the discussion has been about the data element and the time element so maybe:

"Should HTML5 have a time element"
"Should HTML5 have a data element"

This does not really cover the pubdate attribute or the atom conversion section. But on the other hand I don't really object to removing them.

> http://lists.w3.org/Archives/Public/public-html/2011Mar/0586.html
> http://lists.w3.org/Archives/Public/public-html/2010Jan/att-0218/issue-76-decision.html

My issue with the schema.org examples could be handled as a counter-proposal if someone tries to re-introduce them in the spec ( after the revert ).

(In reply to comment #74)
> (In reply to comment #73)
> > Can that be split into smaller issues?
> 
> Yes, I guess most of the discussion has been about the data element and the
> time element so maybe:
> 
> "Should HTML5 have a time element"
> "Should HTML5 have a data element"
> 
> This does not really cover the pubdate attribute or the atom conversion
> section. But on the other hand I don't really object to removing them.

If somebody would like to advocate the removal of pubdate, we would need a Change Proposal.  The question here is whether that should be handled separately from one of those two issues, or can be combined.

The Atom conversion has not been a part of the W3C HTML spec for quite some time:

http://lists.w3.org/Archives/Public/public-html/2010Jun/0000.html

> > http://lists.w3.org/Archives/Public/public-html/2011Mar/0586.html
> > http://lists.w3.org/Archives/Public/public-html/2010Jan/att-0218/issue-76-decision.html
> 
> My issue with the schema.org examples could be handled as a counter-proposal if
> someone tries to re-introduce them in the spec ( after the revert ).

Tantek has begun work on such a change proposal:

http://lists.w3.org/Archives/Public/public-html/2011Nov/0026.html =>
http://www.w3.org/wiki/User:Tantekelik/data_element

If the people interested in this topic can work together and a single Change Proposal emerges, we can issue a Call for Consensus on that proposal.  If a common proposal can't be reached, we will issue a call for Counter Proposals.

(In reply to comment #75)
> If somebody would like to advocate the removal of pubdate, we would need a
> Change Proposal.  The question here is whether that should be handled
> separately from one of those two issues, or can be combined.
> 

I advocate for the removal of pubdate for the same reasons given in the bug report, specifically comment 7. This is a minor change and should be regarded as a cleanup from the old atom integration. The change proposal will only include removal, not replacement.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14202#c7


(In reply to comment #73)
> Can that be split into smaller issues?

I do not think this can be split into multiple bug items as the prerequisite question is for the use case of if\how to represent elementary data within html. <time> is an implementation of this for a single element type and so is superseded by any <data> discussion and resolution.

as noted on public-html:

"The problem with having both <time> and <data> elements is their overwhelming overlap in functionality and implementation. If we need <data>, why do we need a special case for <time>?"

http://lists.w3.org/Archives/Public/public-html/2011Nov/0055.html

http://www.w3.org/html/wg/tracker/issues/183 - enhance-time
http://www.w3.org/html/wg/tracker/issues/184 - data-element
http://www.w3.org/html/wg/tracker/issues/185 - drop-pubdate