with decimals and dots

HTML5 number inputs – Comma and period as decimal marks

<input type="number"> will open a numeric software keyboard on modern mobile operating systems. Not every user can input decimal numbers into this convenient field without proper localization. Half the world uses a comma and the other half uses a period as their decimal mark. (In Latin scripts.) Does your web application take that into consideration? Do the browsers?

Why <input type="number"> and what is the problem?

Touch software keyboards, or “soft keyboards”, can adapt to the input type that is requested from the user. If an email address is requested for a login, the soft keyboard can be made to include an at sign. For numeric input, the keyboard can include larger numbers like on a dialpad, a decimal mark, and a minus sign. These adaptive soft keyboards are a big convenience to users as they do not have to manually change the views of their already‐hard‐to‐use keyboard.

The problem with these soft keyboards and even with regular analog keyboards, is the decimal mark. Roughly half the world uses a comma as their decimal mark, and the other (mainly former colonies of the British Empire) uses a period instead.[1] In computing, decimal marks are usually presented in a way following the locale of system. However, the stored value in memory is always represented with a period.

Inputting an invalid value into a <input type="number"> will, as per the specification, set the value to an empty string. The value presented to the user will still be whatever they typed, but the form will not actually submit any data. This is a big usability as well as functional problem for web applications.

What does the W3C recommendation say?

The value of an <input type="number"> must always be either a valid integer (number) or a valid decimal number. The specification defines the decimal separator as a period regardless of the locale.[2] However, the value the user inputs or the value that is displayed to the user does not need to meet this technical requirement. The specification does not define how exactly this should be handled, but suggests the following:

“Browsers are encouraged to use user interfaces that present […] numbers according to the conventions of either the locale implied by the input element’s language or the user’s preferred locale. Using the page’s locale will ensure consistency with page‐provided data.” [3]

Additionally, all browsers except Internet Explorer will strip any whitespace characters and thousand separators (space, comma, or period depending on locale  —  see below) from the value.

Following this logic we can make a test[4] and get the following web browser support comparison chart:

Browser support

UI language refers to the user interface language of the browser or operating system as set by the user. Element language refers to the language of the form widget (<input type="number" lang="nb">) or page (<html lang="nb">) as set by the page author. In the table, Norwegian represents the comma‐locales and English represent the period‐locales.

Recognized decimal marks
English UI and element English UI and Norwegian element Norwegian UI and element Norwegian UI and English element
Mozilla Firefox 35 period period and comma period and comma period and comma
Google Chrome 40 period period period and comma period
Opera 27 period period period and comma period
Safari 4 (OS X) period and comma
Internet Explorer 11 Unsupported
Windows Phone 8 and 8.1
Internet Explorer Mobile 10 and 11 Unsupported
iOS 8
Safari Mobile period and comma
Google Chrome
Opera Coast
Android 4.4 and 5
Mozilla Firefox period period period period
Google Chrome period period period and comma period and comma
Opera Mobile period period period and comma period and comma
WebView period period period and comma period and comma

I have not made any investigation into support of Arabic or other script’s decimal marks. I would expect the results to be similar or worse.

Notes on browser support

Those familiar with the browser landscape might recognize that Google led projects — Blink/Chromium (used by Chrome, Opera, Yandex, Vivaldi, and others) and Android — have the most problems. There is an ongoing discussion that holds promises for their implementations to be fixed. Even if that discussion bears fruits in the near future, end‐users will still encounter problems on older systems that do not necessarily receive updates.

Apple’s implementation in Safari and iOS is noteworthy. Instead of relying on hints from the locale or page author, the browser allows interchangeable use of commas and periods in all locales.

Internet Explorer does not support number inputs, as defined in the HTML5 recommendation. It does support bringing up numeric software keyboard if the input element sets its type to number. This is kind of okay, as user‐provided input can be validated and corrected with JavaScript or server‐side.

Recommendation for web authors

Set the form language explicit as an attribute of the input element or the form itself. For example, <input type="number" lang="nb"> Web pages do not always set the language on their root element. For form input, this actually matters and setting it on the form or input element will help your users complete the task of filling in numbers.

I’m almost tempted to recommend you always set the input language of all <input type="number"> to a locale that uses commas to get both period and comma support. This could cause issues in the future if browsers decide to stop supporting periods when commas are expected. As of today, however, this is not the case but could change.

The value of an <input type="number"> is always — except in Internet Explorer — set to a valid decimal number. There is no way to read the raw value the user input. When an invalid value is provided, the display value is left as the user provided it. However, the value is cleared and set to an empty string. This is the expected behavior!

Some browsers will validate the input and confusingly show a red border around the input. Thus prompting the user to correct the input. This can be somewhat unclear to the user. Using JavaScript, the input element’s valid property from ValidityState can be tested. This can be used to display a custom error message, shake animation, or otherwise prompt the user to correct the information. Another way with more reliable support is to read the input element’s input event. Process the event by checking that the input element’s value is not an empty string and is a valid decimal number (for Internet Explorer and legacy browsers), and then prompt the user to provide a valid input. Using the input event is highly encouraged over other events (like key, paste, or change) as this support clipboard, keyboard, handwriting, IME, and other forms of input. Consider using the widely supported blur event as a fallback for legacy browsers, even though it is less reliable than the input event.

It is hard to instruct the user on what input is expected as you cannot test whether the form will be localized or not! Every browser supports input with a period as the decimal separator, so this can safely be used. To reduce the chance of errors, you could consider setting the input element’s placeholder attribute to a valid floating‐point number even when this does not match the user’s locale.

Having a fallback parsing in JavaScript is recommended as older browsers do not support numeric input types. Take care to ensure that any server validation is identical to the client-side validation done by the browser (with type="number") and in JavaScript.

Recommendation to implementors (browsers)

Please support period and commas used interchangeably as the decimal mark regardless of any locale hinting. Apple has got the right idea here!

When it comes to thousand separators[5], it is simply a matter of stripping out every decimal mark symbol (whether it be a period or a comma) except the last one. The International System of Units (SI) recommends using a space to group digits to reduce format confusion. After reading this article, I hope you agree.


1 thought on “HTML5 number inputs – Comma and period as decimal marks”

  1. Thanks for the comprehensive blogpost..
    As an update, I tried implementing the lang= attribute and found that even with it, the latest Chrome (Version 52.0.2743.116 m (64-bit)) doesn’t allow me to enter any comma into a type=’number’ input. (I tested using german locale. de-DE, with step=’any’ and various ‘pattern’ attributes.)

    So we haven’t found a cross browser way have numeric keyboards on mobiles for our responsive platform. Had to revert to type=’text’

Leave a Reply

Your email address will not be published. Be courteous and on-topic. Comments are moderated prior to publication.