search

openui / open-ui

Maintain an open standard for UI and promote its adherence and adoption.
https://open-ui.org
Other
3.49k stars 186 forks source link

<measure> web component #499

Open futekov opened 2 years ago

futekov commented 2 years ago

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 a datetime attribute, the new <measure> element might have a set of unit and value attributes.

Example:

<data unit="meter" value="2">2m</data>

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.

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

futekov commented 2 years ago

Problem

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:

Current Solutions

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.

Recommended Solution

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.

Other solutions

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.

Open Questions

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.

yinonov commented 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:

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

christopherallanperry commented 2 years ago

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.

bkardell commented 2 years ago

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

futekov commented 2 years ago

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

jonathantneal commented 2 years ago

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.

Prior Art

css-meeting-bot commented 2 years ago

The Open UI Community Group just discussed Measure element proposal, and agreed to the following:

The full IRC log of that discussion <gregwhitworth> Topic: Measure element proposal
<gregwhitworth> github: https://github.com/openui/open-ui/issues/499
<gregwhitworth> scribnick: JonathanNeal
<gregwhitworth> scribenick: andrico1234
<andrico1234> futekov: have a web component 'measure'
<bkardell_> present +
<andrico1234> ok!
<gregwhitworth> futekov: *presents presentation* (we'll link to it later)
<gregwhitworth> q?
<masonf> TIL: UK cups are different from US cups.
<gregwhitworth> same
<una> +1 😂
<gregwhitworth> q?
<bkardell_> q+
<una> It sounds like internationalization for units
<gregwhitworth> ack bkardell_
<JonathanNeal> I don’t have a question, but I do want to express my support. Wow and thank you.
<andrico1234> bkardell_: left a comment on issue, that INTL in JS is having alot of success in defining how these things work. thinking about that enables all sorts of interesting things
<andrico1234> bkardel: i get why we want this in markup, but there are microdata solutions now, how many people are using them. there was more than one, one was adding units and measures. it's a difficult set of challenges, and the INTL path probably involves the least question but still a mountain of questions. my suggestion to focus first
<andrico1234> bkardell_: HTML has 130 elements, and most have relatively weak semantics, and don't do too much in the browser, but we spend a lot of time working on them. those are less valuable unless we can get them right. have INTL support will help us get working with web components
<gregwhitworth> q?
<davatron5000> q+
<gregwhitworth> ack davatron
<bkardell_> +1 to the apology
<gregwhitworth> q+
<masonf> q+
<andrico1234> davatron5000: i wanna apologise for america! it looks like INTL should go first, and this is a really cool idea
<masonf> q-
<andrico1234> gregwhitworth: i know presenting is daunting! so thanks for taking the time and a wonderful walkthrough. many of us didn't realise htere was difference between US and imperial units. at Salesforce, we spend a ton of time doing currency conversions. one thing I agree we should piggy back on INTL. this feels like a declarative form of that. the browser could switch values, as a web dev, i would want that as well, but i don't want to discu[CUT]
<bkardell_> q+
<andrico1234> gregwhitworth: like a picture element, if someone authors something in celsius it render something in whatever value, if i change the value it would change the rendered text.
<andrico1234> gregwhitworth: from all the time i see web dev doing data conversions, like what google's doing for all manner of metrics, you can then use the URL to change the unit on the client. i am supportive! from a declarative perspective i love it
<andrico1234> masonf: I was gonna say +1
<gregwhitworth> ack gregwhitworth
<andrico1234> bkardell_: most of this is +1 too!
<gregwhitworth> ack bkardell_
<andrico1234> bkardell_: I regret not saying nice job so... nice job!
<andrico1234> bkardell_: i like the idea of custom elements, because I can imagine useful interactions around this and give people ability to play with that, though not sure what it looks like. giv epeople powers and 1000 flowers can bloom
<andrico1234> gregwhitworth: what's your action you're looking to the group for
<andrico1234> futekov: i was looking for validation, as a dev I would love to use this. helps with a simple computation on a phone or computer, and wanted to propose
<andrico1234> futekov: it would be very useful for many people, since hundreds of thousands of people search conversions a day
<scotto_> awesome job presenting. some things beyond what other have mentioned, is that this seems like something that should potentially also respect explicit instances of the lang attribute. - particularly in the case where there might be a browser feature to auto-convert unit instances, but may need to respect a specific language's representation of units
<andrico1234> futekov: would help make content more accessible, easier to digest and understand. i want to see if people like, though I'm not sure the process for new elements
<andrico1234> futekov: you all seem enthusiastic enough
<andrico1234> gregwhitworth: all i've seen is support, so it looks like you want to push this forward asn element. i want to push this to the group. OpenUi wants to figure out what all it's lanes are
<andrico1234> gregwhitworth: do we want OpenUI to act as incubator for this element, or do we want to recommend what to do specifically?
<andrico1234> gregwhitworth: we could start off with a custom element, then we can spec that to turn it into an element
<JonathanNeal> I would love to help with this in OpenUI. Start to consider some of these great questions scotto_ and bkardell_ have mentioned.
<andrico1234> gregwhitworth: we could incubate it in open ui, we've also been picking up primitives. we could also say that this is an element aand we might not want to tackle as a grou. what do we want do ?
<andrico1234> JonathanNeal: with HTML prototyping, the line is alreayd blurry, so i would love to help with this, without answering whether it's an element, interface, or anything like that. we could respect that it could be something abstract
<andrico1234> JonathanNeal: while working at during the open UI
<andrico1234> masonf: +1, this is a problem statement, and a very real problem. an element is one solution, and chatting about it in this groupis what we could do. it could even be an attribute
<andrico1234> gregwhitworth: does anyone object to this?
<andrico1234> bkardell_: there's a problem exactly on this in the ECMA script group that discusses this
<davatron5000> no objections!
<JonathanNeal> And I think whether it is an element or an attribute, CSS could get involved. e.g. prefers-unit :)
<gregwhitworth> RESOLVED: Open UI to incubate a solution to semantic measurements
<JonathanNeal> I don’t know, and I would love to explore the space.
<andrico1234> gregwhitworth: thanks so much Alexander for taking the time
<andrico1234> gregwhitworth: next item lightdismiss on page scroll
gregwhitworth commented 2 years ago

@futekov I think this issue can be closed out, what do you think?

github-actions[bot] commented 1 year ago

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.

Crissov commented 1 year ago

Would this also cover fiscal data, i.e. monetary amounts where the unit is a currency?

futekov commented 1 year ago

Those are very different since their exchange rate fluctuates constantly, while all physical measurements have "fixed" ratios between the different measurement systems.

Crissov commented 1 year ago

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.

github-actions[bot] commented 11 months ago

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.