A new change is being currently rolled out that changes how decimal inputs are parsed in the Input element (any decimal input, so that includes Currency, etc). I wanted to write this post to explain how it works, the rationale, and answer any questions people may have in case something is unclear or ambiguous.
The current (soon to be previous) way decimal inputs are parsed is based purely on the app’s language, and a language convention (which we did not design). In practice this can be mildly annoying. In spanish, for example, someone could write “1.5” and the language convention dictates that “.” is the thousands separator, so that should not work at all, since technically it does not make sense as a number. We currently just get rid of the “.” and interpret it as 15 which is still not great because we could reasonably say that the user meant 1.5. There are plenty of such examples where relying solely on the language convention is too constraining for the users.
The new (soon to be current) way decimal inputs are parsed uses a combination of
a) trying to guess what the user intended to write and
b) the app’s language and a language convention
The new parsing mechanism basically looks at the number on its own and guesses what the user was trying to write, then, in combination with the language specific convention and the app’s language creates a final determination of what the user meant. In practice this looks like the following.
- ‘Common sense’ parsing: In all languages, “1,234.5” and “1.234,5” will be parsed as 1234.5 even though, say in spanish, these should be nothing and 1234.5 respectively.
- If there is no clear ‘common sense’ interpretation then we disambiguate based on the language settings. For example, in spanish “1.500” would be 1500 because, in spanish, the language convention is that “.” is a thousands separator and in that number it is placed in a position such that it can be a thousands separator. One could argue that the user meant 1.5 but because it is ambiguous, we default to the language convention.
Note that this can result in users experiencing some perhaps unexpected behavior. For example a user in spanish could type “1.51” and that would be parsed as 1.51 but then if the user adds a 2 at the end to make it “1.512”, it will be parsed as 1512, and then if the user added a 3 to make it “1.5123”, it would be parsed as 1.5123. We understand this is not ideal yet and we will keep working to improve this, but we believe the benefit from making the input more flexible and tolerant will be a better experience for users. Personally, I hate when I’m on a website and start writing a decimal number only to realize I should be using a “,” instead of a “.” for my decimals. This feature is intended to reduce the amount of times users find themselves in that situation.
Finally, note that you can avoid the potentially inconsistent behavior if you know that your users will only ever need decimals up to 1,2,3, or 4 digits you can set that up via the Decimal place dropdown in the Input element.
Any thoughts, questions or concerns are welcomed
