Proposal: new element for measurements <m>

[futekov]

The proposed measure element would be a text-level element representing a physical attribute such as length, area, volume, mass, weight, temperature, speed, acceleration, etc.

Syntax

<m unit="mi" value="20">twenty miles</m>

Rationale

The measuring systems in modern use are the metric, imperial, and US customary systems and web users are forced to interrupt their browsing journey to convert units that are not native to them.

Google Search has been answering conversion queries for at least 16 years so we can infer that the demand for unit conversion is indeed huge.

A <m> element would provide standardized hooks for measurements, which would make client-side conversion of units between measurement systems much easier to accomplish. Any site would then be able write a script to convert it, browsers extensions could be easily created to convert units across the web, and browsers themselves could offer it as built-in function similar to page translation (available in Chrome and Safari).

Use cases

• for any objects with physical dimensions, such as consumer products, tech hardware, furniture, etc
• for recipes that contain cooking measurements in units like cups/ounces/liters/grams
• for weather forecasts that show measurements for temperature (°F or °C), precipitation, wind speed, etc
• for cars/machinery specifications such as dimensions, torque, acceleration, weight, fuel efficiency, and working temperatures

The <time>, <a>, and <abbr> elements in HTML already expect information for one entity in two formats - one user-facing text content between the opening and closing tags, and one attribute value usually following a certain protocol/standard.

Future Development

This new element would become much more powerful if a new browser/OS preference for metric/imperial/US customary units can be introduced within the Intl or Navigator objects. This would allow any script to automatically convert measurements when appropriate for a given user (similar to how browsers offer page translations).

A convert attribute convert="never|auto|eager" or similar would hint which measurements are (not) suitable for conversion.

An examples of how this element might look like in the real world:

<p>The new CPUs use a <m unit="nm" value="5" convert="never">5nm process</m>.</p>

<p>The length of the <dfn>Great Wall of China</dfn> is <m unit="km" value="21196" convert="eager">21,196 km</m>.</p>

I've written a more detailed explanation on why such an element would solve many problems, it also includes sections on why writing a parser couldn't achieve the same results and why I think microformats are inferior to a brand-new text-level element.

[Yay295]

I think for the common case of a number followed by a standard abbreviation it would make sense to not require the unit and value. That is, <m unit="km" value="21196" convert="eager">21,196 km</m> could be written as just <m convert="eager">21,196 km</m> since it's easy enough to parse the text.

Also shouldn't <m unit="nm" value="5" convert="never">5nm process</m> be <m unit="nm" value="5" convert="never">5nm</m> process (which could then be shortened to <m convert="never">5nm</m>)?

[futekov]

@Yay295 you're right, "process" should be after the closing tag.

Parsing is pretty simple when you have everything formatted as number + unit, however there are plenty of cases that are hard or impossible to parse, some examples:
10 m - ambiguous abbreviations
two ounces - number words are sometimes used instead of digits
4 kilos - shortened or slang words for units
half a gallon - multiple words
weights just under a pound - being imprecise in the text
quatre-vingt seize litres - units and values in a different language
5′ 11″ - feet & inches often use quotes, primes, apostrophes, carets or similar symbols - ′'‘’ & ″"“”

Using a standardized way to enter units and values would solve all these without a complex parser (even google's search engine can't get all of the above right).

[Yay295]

Which is why I specified "for the common case of a number followed by a standard abbreviation". I did read your more detailed explanation first.

[domenic]

Thanks for the suggestion! However, HTML already has you covered: you can use the <data> element and its value="" attribute, plus the microdata attributes to associate metadata such as unit.

One simple example of this would be the following, which I made up off the top of my head:

<data value="20">twenty <span itemprop="unit">miles</span></data>
<data value="2" itemscope>two ounces<meta itemprop="unit" content="oz"></data>

but probably you want to use one of the more standardized examples from https://schema.org; from what I can tell QuantitativeValue might be what you want.

I'll close this, since the general problem of providing structured data for tools has been solved generically using <data> and microdata, and HTML won't be accepting new elements limited to specific types of structured data.

[futekov]

<data> is indeed a valid solution, when I read the spec I thought HTML is open for other structured data elements given that <time> exists and is defined as a specific exception to <data>. Because of how common physical measurements are everywhere across the web, my reasoning was that a dedicated measurement tag can get similar treatment to <time>.

Even if we use <data> my point still stands that the web will benefit if a standard for units was implemented. The codes from the Schema.org unitCode are neither intuitive nor user/developer-friendly. And using "oz" for ounces might sound straightforward but it is an ambiguous abbreviation. A standard is needed to differentiate between dry and fluid ounces, also, without leaving the topic of volume typically used in cooking - fluid ounces, gallons, quarts, pints, cups, tablespoons, and teaspoons are all units that have different Imperial and US values.

Many other units are also problematic (such as writing "square/cubic meters" without resorting to superscript symbols) and until there is a universally accepted standard there won't be a simple way to make all these machine-readable. I opened this issue specifically as a way to solve machine-readability, which will then make unit conversions a trivial matter. All other attempts by 3rd party extensions and microdata to solve this problem have failed.

The problem that I think deserves solving is helping people use the web seamlessly and across cultures and barriers as Sir Tim Berners-Lee intended:
The essential property of the World Wide Web is its universality.
I hope we will use the Net to cross barriers and connect cultures.

Even if the existing <data> element is used, usage without microdata will be less verbose, less prone to typos, much easier to use by developers, and won't have to include meta tags:

<data value="2" itemscope>two ounces<meta itemprop="unit" content="USfloz"></data>
<data unit="USfloz" value="2">two ounces</data>

Here's a rough sketch of what interface I believe would make browsing much easier:

I think we can all imagine the translate popup asking us whether we would like the units translated on the page for us by the browser. This is just my vision of a better browsing experience that can skip borders and become more accessible for everyone.

Thanks for the time and I hope you reconsider, manual and tedious unit conversion is a problem that can be solved.

[futekov]

@domenic @annevk - please correct me if I posted in the wrong repo. I was hoping at least for a discussion, the element might be debatable, but the problem users face every day is real and a solution can be reached.

[annevk]

I recommend reaching out to https://wicg.io/ and see if you can turn this into a compelling case there.

[jcobban]

One of the issues is that cooking ingredients which are measured in the Imperial and US Customer systems using "dry measure" volumes are measured in grams in the SI metric system.

One of my hobbyhorses is that in the US customary system the pound, abbreviation "lb" is used interchangeable for both units of mass and units of force. For example in aerospace engineering the performance of an engine is measured as pounds(force) divided by fuel rate (pounds (mass) per second) to produce the Specific Impulse in seconds! In metric you divide the thrust in newtons (force) by the fuel rate in kilograms (mass) per second to get the effective velocity of the exhaust in m/s. The effective velocity is the specific impulse multiplied by the acceleration of gravity 9.80665 m/s².