hi, what about
<measure lang="it" value="12" unit="KG">12 chilogrammi</measure>
UAs can provide inline tools for displaying measurement as specified by user locale (for example in US kg->lb)
or spec can generalize <time> to <measure> any localized data
<measure unit="DATETIME" lang="it" value="2007-10-05">dieci maggio duemilasette</measure>
(In reply to comment #0)
> <measure lang="it" value="12" unit="KG">12 chilogrammi</measure>
Minor nit pick: The symbols for SI prefixes, base units and derived units are case sensitive ("kg" is lowercase). Otherwise units like mm (millimetre) and Mm (Megametre) would be indistinguishable. I think the only exception to this is the Litre, for which both L and l are acceptable.
But I question the use case for this. If the whole page was in Italian, and the author had written "12 chilogrammi" instead of "12kg", then it seems like a safe assumption that the reader would understand Italian enough to know what "chilogrammi" means.
> UAs can provide inline tools for displaying measurement as specified by user
> locale (for example in US kg->lb)
This example may be slightly more common, as people outside the US and UK tend not to be so familiar with imperial and US customary units. But in contexts where such conversion matters, it's common for both customary unit and SI unit to be given together. I'm not entirely convinced that this is necessary.
There are also many ambiguities for some non-SI units that use the same name and symbol for different definitions in different contexts or countries. So that would have to be taken into account with this proposal.
>But I question the use case for this. If the whole page was in Italian, and
>the author had written "12 chilogrammi" instead of "12kg", then it seems like a
>safe assumption that the reader would understand Italian enough to know what
I'm italian and i can read and understand english, but if I read "12 miles" i know "mile" as measurement unit, but i'm not practice with in-my-mind-conversion to my more familiars kilometers
another useful feature for <measure> can be real-time currency conversion
<measure unit="EUR" value="1234.33"> 1.234,33</measure>
ua can show/tip the money as specified by the user locale
in plus crawlers, bot, can understand better technical data (and prices, and much more) independently by page localization and/or page language
I'm considering merging <time> and this and various other similar ideas into one element that can be used in microformats, microdata, or RDFa to just mean "here is the machine-readable hidden data form of some human-readable visible data".
An dedicated element for this purpose seems a bit odd, a lot of the time you're going to already have an element, so a global attribute such as itemvalue="" seems a more sane solution if we want to make it easier for people to use hidden metadata.
As for <time>, throwing it out seems perhaps a bit drastic, but on the other hand it isn't very useful currently because not many kinds of times can be marked up with it (such as YYYY, YYYY-MM, durations, re-occuring weekly/monthly/yearly times. People are going to want to mark up times a lot with microdata, so perhaps widening the array of things you can express with it would be a good thing...
To be clear: Unless there's a wide range of data that needs different representations for humans and machines *apart from time*, then I'd prefer not having a global attribute (forcing people to use the ugly <meta>) and instead making <time> for useful.
Mass move to "HTML WG"
Changing status to NEW as it seems odd to have a dave.null bug marked ASSIGNED.
Bug 12318  requests a new semantic element: <measure> to be able to mark up additional measurements for machine readable processing. This is very similar in principle to the <time> element, but somewhat more generic (for measurements). It was proposed that either the <time> element be extended to support more generic scenarios, or that a new element (like <measure>) be created but for the specific purposes of marking up machine-readable content.
Since this bug was filed, a proposal exists  for a new <data> element which looks like it meets the use case described in this bug.
Is <data> a useful new tag?
Is <time> still useful? Should it be enhanced to allow for additional scenarios?
If <data> seems useful, then we could resolve this bug by either bringing <data> directly into HTML5.1, or creating an extension spec for <data> (or something like it). Otherwise, we might as well resolve this bug won't fix.
(In reply to comment #9)
> Bug 12318  requests a new semantic element: <measure> to be able to mark
> up additional measurements for machine readable processing. This is very
> similar in principle to the <time> element, but somewhat more generic (for
> measurements). It was proposed that either the <time> element be extended to
> support more generic scenarios, or that a new element (like <measure>) be
> created but for the specific purposes of marking up machine-readable
> Since this bug was filed, a proposal exists  for a new <data> element
> which looks like it meets the use case described in this bug.
> Is <data> a useful new tag?
> Is <time> still useful? Should it be enhanced to allow for additional
> If <data> seems useful, then we could resolve this bug by either bringing
> <data> directly into HTML5.1, or creating an extension spec for <data> (or
> something like it). Otherwise, we might as well resolve this bug won't fix.
>  https://www.w3.org/Bugs/Public/show_bug.cgi?id=12318
>  http://www.whatwg.org/specs/web-apps/current-work/#the-data-element
I've done some work into this area through the time\data debate which was logged under issues 183 and 184. If you have a look at my proposals from each you'll see how far i got in trying to plot a direction for this expanding area of functionality and use cases. I haven't done any further work on it since as the emphasis is on HTML5 and, especially with plan2014, the amount of work required wouldn't line up with that development timeframe.
That being said, i believe that for HTML5.1 this could be one of the most significant areas of new functionality with the express interest in developing greater automation and personalization within the browser for unit conversions and preferences, and also aiding document processing.
The primary open question from which all further work would be defined is that of a single general-purpose <data> element, or multiple domain-specific elements for each refined data-kind. The implementation of <time> falls under the latter and, in my analysis, is a duplet data structure shared between the element and value attribute, with distinction encoded within the value syntax. The former approach of <data> is a tuplet of element, type and value, with global distinction defined within a single type discriminator. The hypothesis which i put forward is that a tuplet-based structure is more capable of distinct and flexible data encoding. If it's good for RDF, Microdata and DNA Codons, it should be suitable for a future-proof HTML Type System.
Look forward to more discussions and keen to work towards an extension spec for HTML 5.1
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:
Status: Additional Information Needed
Change Description: No spec change
Excellent candidate for an Extension spec. As Cameron suggested, there's a big opportunity to work out how <data>/<meter> could be brought together along with the use cases for such a venture.