Create input unit attributes

[shakyjake]

Hiya,

I think it would be useful if we had unit attributes for number inputs to give users a better understanding of what the value is. Currently I just use absolutely-positioned spans to achieve this but I feel like there should be a semantic (and easier) way of doing it.

Visual Output Example:

There would need to be two not-mutually-exclusive attributes (e.g. unit-before and unit-after) to account for different cultures/units/use cases. These would be displayed inside the input, with the caret moving to account for them.

I can only really see these being useful for number inputs but if anyone has a valid use case then feel free to chime in.

[Yay295]

Instead of unit-before/after, something like text-before/after might be better. You've only used units in this case, but someone might want to use it for something else.

[keithamus]

before and after might not be ideal concepts as they are locale dependant (and could change per locale). It might be worth instead expressing the unit type as part of the input, for some background research take a look at the unicode CLDR for units, Intl.NumberFormat, etc.

[shakyjake]

Instead of unit-before/after, something like text-before/after might be better. You've only used units in this case, but someone might want to use it for something else.

That would be more flexible but perhaps wouldn't be as semantically meaningful

before and after might not be ideal concepts as they are locale dependant (and could change per locale). It might be worth instead expressing the unit type as part of the input, for some background research take a look at the unicode CLDR for units, Intl.NumberFormat, etc.

Yup, you're right. I guess we'd have to have something like unit and unit-type with the user-agent displaying the unit in a locale-appropriate location.

Which then means we'd probably need a non-exhaustive list of unit types - perhaps SI Quantities, currency and a generic one for quantities of things.

e.g.

• length
• mass
• time
• current
• temp
• volume
• luminosity
• currency
• text? other? or perhaps just omit the unit-type attribute?

I'm starting to see why Intl.NumberFormat stopped at currency 😅

[keithamus]

CLDR has a - perhaps what could be considered mostly exhaustive - list of units with their template, for example: https://github.com/unicode-cldr/cldr-units-modern/blob/master/main/en-GB/units.json. A proposal could simply reference the CLDR list and use the templates to drive the representations so for your example weight might be something like <input type="number" unit-type="mass-kilogram"/>

[shakyjake]

Aye, that's ideal actually

[rniwa]

Localizing numbers isn't so simple. If you wanted to have a form for person's height for example, we'd usually express it as 5ft 8in in the U.S. instead of 173cm. And the number doesn't even increment by base 10. So a significant consideration has to be made for the trade off between supporting as much localization as possible while making some localization not make the implementation / behavior complex beyond reason.

[Crissov]

ECMA402 limits the sanctioned single unit identifiers from CLDR that are supported in Intl.NumberFormat:

• mass
  • gram
  • kilogram
  • ounce
  • pound
  • stone
• length
  • millimeter
  • centimeter
  • inch
  • foot
  • yard
  • meter
  • kilometer
  • mile
  • mile-scandinavian
• area
  • acre
  • hectare
• volume
  • milliliter
  • fluid-ounce
  • liter
  • gallon
• time
  • nanosecond
  • microsecond
  • millisecond
  • second
  • minute
  • hour
  • day
  • week
  • month
  • year
• data quantity
  • bit
  • byte
  • kilobit
  • kilobyte
  • megabit
  • megabyte
  • gigabit
  • gigabyte
  • terabit
  • terabyte
  • petabyte
• temperature
  • celsius
  • fahrenheit
• angle
  • degree
• ratio
  • percent