Meeting minutes
eemeli: I'm eemeli, I work on l10n, online there is tantek. t is the author of the explainer
eemeli: we think it might be appropriate to add a new HTML <amount> element to enable new behavior for values followed by unit indicators
eemeli: The sort of behavior that we're imagining is similar to iOS where an amount can be clicked/tapped and you end get an app provided popup of conversions for multiple purposes
… The HTML element would not be exactly the same as iOS because it's not automatic, you'd need to use HTML to specify whether it's an amount
… There is precedent, e.g. in JS with Intl.NumberFormat
we're trying to do the same in HTML
An amount element can have a value and the unit in the attribute. With the presentation specified by the developer
like the <time> element
Or we could have the platform do the formatting, e.g. in the second element, with no text content
Or we could go further with the 3rd example, based on the locale, the usage attribute would specify what context you're trying to express the amount in (e.g. person for a mass)
<tantek> 3.26lb
we could imagine going further with currency formatting
We can do that with Intl.NumberFormat
(<rupees example)
We could do a lot, but at a minimum we could imagine doing something as simple as <time>, and have the browser render more info in a popup
tantek: The first example, would be the v0. If the developer would want something to display if it's not supported with the fallback. You could imagine an affordance to indicate that there is an amount, with a popup similar to iOS
… other example is the firefox address bar
… you can type 1.48 kg in lb in the FF address bar and get the conversion
There's already a bunch of built-in conversion kits in the browser, and it would be nice if web devs could take advantage.
It's like progressive enhancement, on browsers that support it, you can get different conversions, or just see the text if not supported
There's no privacy leak because the popup is handled all client side
since we have the capability in the JS engine, we should do it
<Zakim> nicolo-ribaudo, you wanted to ask about time
nicolo-ribaudo: Is there a plan to introduce that kind of conversion for the <time> element?
<jyasskin> +1
tantek: yeah why not
<Zakim> stephen_mcgruer, you wanted to indicate interest in semantics of amount, for payments
stephen_mcgruer: I'm very interested in the currency use case, for the semantic use case. I can see how the browser could provide useful tools for that. Just wanted to say +1
<jyasskin> Prior art for time: https://
tantek: if you purely offer a semantic element without any UI, often browsers won't do anything. So this is why we want to provide some amount of UX guidance for the browser.
… we're curious what to do for currency? one use case is currency conversion, but that's probably a different scope. How should the conversion be? how recent should it be? Not like converting grams to pounds
eemeli: context is critical, e.g. if you are paying for something you want it to be accurate, but in some other contexts it's not as important.
tantek: it's possible we want a different UX for currencies. and we don't want to de-incentivize people from using the element if it's subpar
eemeli: We would probably want to give back control to the web developer for this kind of thing
johanneswilm: this is great, but sometimes the locale of the computer is not necessarily the locale of the user. like denmark where a lot of people use english. This is a problem for date pickers. Danish gov websites use custom pickers for that reason.
johanneswilm: it would be nice to be able to override the locale to avoid this situation
eemeli: this is a problem that should be addressed, and an override is probably the good way to do that.
johanneswilm: i'm not sure what it means to use kg in the US
eemeli: you can provide the value in the unit you specify and use, and the browser handles the display in the browser
tantek: some of this info can be from the server
tantek: The Danish in english problem is going to be answered by another breakout
tantek: the market has shown that this is useful regardless of the locale
the popup that is shown in the example does not make assumptions about the locale.
Apple has done a good job here of providing a good UX that doesn't get in the way.
we'd probably want to start UX guidance from there.
bkardell: if you read the explainer, there's a long history of this being asked for. It was for in what we want, Open UI, discord. There's a long history. There are details are debatable for sure, like having the browser show stuff. Today if you have your phone and select addresses/phones, there are regexes that do some smart detection that are common. If we could have some kind of hint, we could enhance what we've seen useful in the
past
benoit: What does the usage attribute do? is it for stones/pounds/etc. for people?
<tantek> yes
benoit: For currencies, everything you see is from rates that they get from banks, each provider has their own rates. If you are developing an e-commerce website, you are likely need to do get data from a feed that is from the relevant market. What you see in most places is the middle rate.
benoit: If you auto convert on the site, you could see issues where people are charged differently from what shown
benoit: i love the idea otherwise
benoit: Is there a provision for sub-unit values? e.g. something priced in cents, but bought in bulk
eemeli: we have not considered it yet.
<johanneswilm> (@hsivonen - The Danish railway company DSB is also using a differently configured version of that custom date picker on the Danish version of their site. They just don't rely on the browser's locale. )
tantek: The currency part of this is the most fuzzy, hence the question mark. We brought it up as an obvious extension, but with a lot of challenges
benoit: sometimes merchants want currencies to end in a sharp digit, but conversion can be a problem
cwilso: could we represent this in a simpler format ?
tantek: we could some internal parsing to handle that to avoid using attributes. e.g. putting <time><TIME in ISO format></time> to avoid having to put attributes
<benoit> would this also be useful for composite units? m/s, km/h, L/s, etc. ?
cwilso: you could see issues of attributes not being coherently updated
eemeli: we've been discussing in TC39 an amount object, stage 1 proposal, very early stage. We're considering that problem. We want to solve it.
eemeli: we might end up with a stringified micro-syntax. But we want to make sure HTML and JS is consistent.
cwilso: it's more about consider that in addition to the fallback
<bkardell> could you 'polyfill' the display with some css attribute and generated content rules?
<jyasskin> benoit: Js Intl does support some composite units, and I expect this would match that. https://
eemeli: our initial version of unit identifier is dashed identifier. We want the microsyntax to be different from human input, because it's very variable (like , vs . for decimal separator)
<benoit> recognizing a currency code gets harder if you consider including non ISO 4217 values - like cryptocurrencies
vasilii__: i'm from payments, also here to discuss currencies. I agree the currency problem is very hard. I still think semantic support should be part of v0. because of a11y, agentic use cases, also drawing the comparison with JS Intl API.
jyasskin: there is a lot of prior art for the time version of this. We should figure out how to make time work with the popup, but not block amount.
For amount, have you thought of not matching the locale specified? It's useful for have units converted for an european user reading an US site
tantek: CSS seems right to handle presentational transforms like this.
tantek: There are a lot of JS libraries to do formatting, missed oppotunities in CSS
eemeli: fingerprinting problem to have the content change in place.
jyasskin: we are sending the accept language header anyway, can we just use that?
jyasskin: github developed <relative-time> to have their markup match
CSS makes sense
stephen_mcgruer: i don't know why web developers would adopt this. Sometimes there are cases (e.g. shoe resellers) where they don't want it. Do you have web developer evidence?
eemeli: Having the server sending out responses and the client format this.
stephen_mcgruer: why would the developer do this?
tantek: recipes seems like a good one.
stephen_mcgruer: baking is kind of like currencies
<bkardell> 🎉
<bkardell> MathML
tantek: There is a lot of history of web developers asking for this. An another use case is scientific papers, or being able to markup amounts
<jyasskin> stephen_mcgruer: For your recipe site (if you can stand US measures), you'll like https://
benoit: As a counterpoint to the recipe use cases where all units would change. I want to display a current rate conversion for a handful of currencies. I'm going to do a request and display them one by one, and use each element with different currencies. But no auto conversion. Is that something I can do?
tantek: there is no auto-conversion in v0.
<benoit> +1
<vasilii_2> +1
<bkardell> but you could still have extensions or apps that do that other stuff
<bkardell> Maybe it could use XSLT 3
<bkardell> :)
tantek: i also prefer not have currencies in v0. Our main use case is kg/lb. I would prefer expanding later as we see people use them.
benoit: If my locale is en-CA, if I want all the values to display properly. Do I need to specify the locale for each currency? Does lang inherit? or does it infer from the unit?
tantek: lang inheritance is a long rabbit hole
<Zakim> nicolo-ribaudo, you wanted to ask about "no text generation"
eemeli: the expectation is not necessarily what the current currency code is, it sometimes the user's locale. e.g. for decimal separators. Impossible to predict, and hard for euro where there is no 1:1 mapping
nicolo-ribaudo: about the comment that there is no text-generation. 1. do I just see ntohing for unsupported browser? 2. Does it not do auto-formatting in the user's locale?
<stephen_mcgruer> +1 to the fact that its hard to keep all the variants here in my head!
tantek: 1. progressive enhancement. 2. we want to be predictable for web developers
<stephen_mcgruer> 1kg, 1 kilogram, 2 kilograms, 1 kilo, 2 kilo, ...
eemeli: what about <amount>1.48[kilogram]</amount>
<stephen_mcgruer> 1 kilometre, 2 kilometres, 1 km, 2 km, 4 klicks, ...
tantek: we should not make up new syntax. it should be syntax that people are already familiar with. don't be more clever than needed, just look at prior research
stephen_mcgruer: humans are not communicating in a standardized way
tantek: There are some scientific standards out there