Open futekov opened 2 years ago
@futekov thanks for filing this. This seems like a reasonable request. Prior to presenting I recommend having an explainer to provide here for review by the group. You can then converted to a presentation to the group. If you already have an explainer please post it.
If you don't, the MSEdge Explainers repo has some great examples. Key things that helps with this is:
This will allow a lot of async discussion regarding it. It's important to understand that an explainer does not need to be a really formal document; you can even just author it in Google Docs/Word Online/Markdown, etc.
Let me know if you have any questions.
Users often interrupt their browsing flow to convert measurement units not native to them. The web traffic for unit conversion is so significant that Google added unit conversion functionality to their search engine at least 17 years ago. Some examples of when users might need such a function include:
The most used solution by users to convert different units of measurements is to open a search/computation engine, a bookmarked page, an extension, or an app and then convert the information there. All of these options:
From the perspective of web authors, some sites try to solve this by implement their own solutions that process specific tags on the server like Wikipedia which processes this tag {{convert|61|mi|km|abbr=on}}
to this text on a rendered page 61 miles (100 km)
. It would be interesting to see how other CMS systems approach this issue, but I don't have any additional insight.
Some web extensions exist that try to solve this problem by parsing the content of web pages, but they fail at detecting units of measurements that are shortened, use slang, are abbreviated or shortened, or are written in another language. Without properly and reliably detecting units of measurement they can't really be useful for seamless conversion.
My suggestion is to agree on a standard for measurement data as is possible with the <time>
element. If web authors use this standard to mark up measurement on their pages this will allow on-demand/automatic translation for users by simple scripts, browser extensions installed by users, or even by browsers themselves. This might work like the Page Translation feature that already exists in Chrome and Safari, translating units is even simpler for machines than converting languages so future implementations would be trivial from a development perspective.
Another solution that would take the burden of conversion off the users' shoulders would be to develop a smart, well-trained AI (not a simple regex parser) that can understand measurement units in their context and then suggest conversion to the user. I would speculate that this will probably be computationally expensive if always done on the client.
What element should be used - the most obvious pick is the existing <data>
. Since the element will need new attributes such as unit
and value
, it might also be a good option to implement an entirely new inline-level element such as <m>
, or <measure>
so that it matches the established pattern of having new HTML elements have their own unique attributes like <time>
and <video>
for example..
Which standards should be used - some candidates that I could find for unit code standard are UN/CEFACT Common Codes, UCUM's units, or Wikipedia's.
@futekov thanks for filing this. This seems like a reasonable request. Prior to presenting I recommend having an explainer to provide here for review by the group. You can then converted to a presentation to the group. If you already have an explainer please post it.
If you don't, the MSEdge Explainers repo has some great examples. Key things that helps with this is:
- What is the problem you're wanting to solve (don't lead with solutions)
- Outline the current way in which web developers currently try to solve the problem
- What is your recommended solution
- What other solutions did you consider
- Open Questions
This will allow a lot of async discussion regarding it. It's important to understand that an explainer does not need to be a really formal document; you can even just author it in Google Docs/Word Online/Markdown, etc.
Let me know if you have any questions.
wish I could star this comment for later...
wish I could star this comment for later...
I'm not sure whether it might be there already, but this would seem to be a good candidate for the main https://open-ui.org/ site, either on /get-involved or /proposal-guide maybe. I know I found it useful. Have a look over there, and if you can't see anything that covers it currently, perhaps raise an issue and reference it back here.
A few thoughts....
First, if this is just 'semantics' authors could do this today with 'bolt on' semantics through schema.org or something, and historically those kinds of things are the things that I feel like standards bodies burn a lot of time on and still somehow get wrong (see <address>
history, for example)... That said, I expect it isn't and there is something worth pursuing here. I think practically it would be more valuable if the component exposed an API that allowed you to convert very easily or even maybe optionally could provide some affordances for letting users do that. However, to do that requires a lot of decisions in terms of how that would work, etc and stops short of providing that sort of functionality in script itself more globally where you need it at least as frequently.
I would note that there is ecma 402 and lots of work on Intl
doing all sorts of this work with some real success, and if we have that, it's easy to point a higher level declarative thing atop of and just say "that's the magic that makes it work" without having to figure all of those things out too. In that, it is worth noting that right now there is a new proposal about unit conversion - so it might make sense to have a look at that and +1 or comment, etc.
In any case, I'm not suggesting something specific beyond "that seems like a very ideal and pragmatic path".
@bkardell I share your thoughts about Schema.org's semantics. If this component is going to have an API it will make more sense to be a separate element IMO (we already have play/pause/etc in <video>
and <audio>
for example).
The TC39 group also considered adding a method to detect a user's preferred measurement system last year, but was dropped as it is not yet mature.
I really appreciate this proposal, I support it, and I would love to help.
We use celsius in our household for the temperature, which is also very helpful when I communicate with co-workers internationally. However, I live in the United States, where most of my region uses fahrenheit. I wish there were a way, any way, to communicate these things in the units I understand.
I have this same issue when viewing recipes online.
Without overloading this proposal — I do hope measuring time may be considered in scope, even if it is not available at first. I have desired this same measurement or conversion for time and relative time, especially when coordinating meetings. I hope <measure>
(or whatever name it becomes) can handle these things for me.
All of these feel appropriately a kind of constant-like measurements.
The Open UI Community Group just discussed Measure element proposal
, and agreed to the following:
RESOLVED: Open UI to incubate a solution to semantic measurements
@futekov I think this issue can be closed out, what do you think?
There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.
Would this also cover fiscal data, i.e. monetary amounts where the unit is a currency?
Those are very different since their exchange rate fluctuates constantly, while all physical measurements have "fixed" ratios between the different measurement systems.
I don’t see how that's ”very“ different.
Btw., some earlier discussion are e.g. found in https://www.w3.org/Bugs/Public/show_bug.cgi?id=12318 or even my naive proposal for <nr>
in https://lists.w3.org/Archives/Public/www-html/2002Nov/0110.html.
There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.
I would like to present an idea for a web component, it's very similar to the
<time>
element in the sense that it's and inline element with an attribute that accepts a value of a certain standard. While<time>
has adatetime
attribute, the new<measure>
element might have a set ofunit
andvalue
attributes.Example:
This web component could reuse the existing element
<data>
, or introduce a new one (e.g.<m>
,<measure>
).The main purpose would be to standardize an API that will allow physical measurements to be machine-readable and thus easier for automatic/on-demand conversion which can aid a11y for users of varying locales.
Some candidates that I could find for unit code standard are UN/CEFACT Common Codes, UCUM's units, or Wikipedia's.