This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12318 - feature request: a more semantic tag for non-intl-measures?
Summary: feature request: a more semantic tag for non-intl-measures?
Status: RESOLVED NEEDSINFO
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P4 enhancement
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-16 16:09 UTC by Giorgio
Modified: 2013-03-05 00:17 UTC (History)
9 users (show)

See Also:


Attachments

Description Giorgio 2011-03-16 16:09:57 UTC
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>
Comment 1 Lachlan Hunt 2011-03-17 12:19:44 UTC
(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.
Comment 2 Giorgio 2011-03-17 14:22:29 UTC
hi,

>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.

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
Comment 3 Ian 'Hixie' Hickson 2011-06-14 22:50:37 UTC
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".
Comment 4 Philip Jägenstedt 2011-06-15 09:40:23 UTC
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...
Comment 5 Philip Jägenstedt 2011-06-15 09:43:11 UTC
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.
Comment 6 Robin Berjon 2013-01-21 15:58:24 UTC
Mass move to "HTML WG"
Comment 7 Robin Berjon 2013-01-21 16:01:11 UTC
Mass move to "HTML WG"
Comment 8 Edward O'Connor 2013-02-28 23:15:47 UTC
Changing status to NEW as it seems odd to have a dave.null bug marked ASSIGNED.
Comment 9 Travis Leithead [MSFT] 2013-03-05 00:16:45 UTC
Bug 12318 [1] 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 [2] 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.

Thoughts?

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=12318
[2] http://www.whatwg.org/specs/web-apps/current-work/#the-data-element
Comment 10 Travis Leithead [MSFT] 2013-03-05 00:17:24 UTC
(In reply to comment #9)
> Bug 12318 [1] 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 [2] 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.
> 
> Thoughts?
> 
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=12318
> [2] http://www.whatwg.org/specs/web-apps/current-work/#the-data-element

Hi Travis,

I've done some work into this area through the time\data debate which was logged under issues 183[1] and 184[2]. If you have a look at my proposals from each[3][4] 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.

There is a natural synergy with data-markup technology (RDFa, MIcrodata) which could be argued as being the space for data typing, however the space for times, units, measurements is more quintessential and more naturally aligned to programmatic datatypes, hence the recommendation that this could form a "HTML Type System" with direct integration with the HTML input types and Javascript data structures\functions.

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

Thanks,
Cameron Jones

[1] http://www.w3.org/html/wg/tracker/issues/183
[2] http://www.w3.org/html/wg/tracker/issues/184
[3] http://www.w3.org/wiki/User:Cjones/ISSUE-183
[4] http://www.w3.org/wiki/User:Cjones/ISSUE-184
Comment 11 Travis Leithead [MSFT] 2013-03-05 00:17:57 UTC
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: Additional Information Needed
Change Description: No spec change
Rationale:

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.