The State of HTML5 Input Elements

Recently I was working on a project where we required date and numeric fields. Being a purist, my preference is and always will be native elements over some bloated JavaScript library. “Polyfills can cover outdated browsers,” I thought, “that way we keep the best experience on modern browsers.”

That particular project would ship in several countries in Europe. Pretty much each country has their own way of formatting dates and numbers. This made me curious about the following:

• Can the HTML5 input field’s locale be influenced?
• Is the field’s expected value format obvious?
• Do browsers prevent misinterpretation any other way?

As (Un)defined by the Specification

W3 has a few paragraphs dedicated to localisation of HTML5 input elements:

“The time, date, or number given by the page in the wire format is then translated to the user’s preferred presentation (based on user preferences or on the locale of the page itself), before being displayed to the user. Similarly, after the user inputs a time, date, or number using their preferred format, the user agent converts it back to the wire format before putting it in the DOM or submitting it.” – 4.10.1.5 Date, time, and number formats

“Browsers are encouraged to use user interfaces that present dates, times, and 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.” – 4.10.5.2 Implemention notes regarding localization of form controls

The specification states input should inherit the locale from the page or the user settings. The spec also states why the page’s locale is preferred over user settings. Unfortunately, no further information is provided about how a browser should display the expected format.

The Issue

The specifications obviously recommend rendering the elements in the locale of the user or page. Unfortunately, some browsers just use the user’s locale, not the page’s. This could cause some confusion and invalid input.

Consider the following example:

This all seems normal from an English context. Meanwhile, in some office: “Huh. A Dutch person inserted a BMI of 25 thousand. That one person must be as big as the country itself! LOL.” If the browser chooses a Dutch locale for the number field, and the user assumes English format is required because it’s an English page after all, the browser will interpret and submit the value wrong.

The Solution

Clearly, plain input fields are not enough to prevent confusion and errors. The solution is rather predictable:

• Show the expected format
• Constrain user input

If the browser always inherits the page locale, a hint can be built in the application. No big deal.

If we can’t be sure what the browser inherits, the hint becomes the browser’s responsibility. Hinting via placeholders is one possibility, but those aren’t visible when a field is prefilled. Tooltips or something similar may overlap with application tooltips or other content.

Constraining input is another option. This can be as simple as ignoring characters, or specifying a format using the pattern-attribute. For more complex values, a popup can be used that only allows users to pick a predefined value, like a calendar or select box.

What Browser Does What

As the specs aren’t very explicit about how browsers should implement locale detection or how the inputs should work, current implementations are very different. I answered my three questions by testing the following three questions per browser:

• How does a browser determine a field’s locale?
• How is the field’s expected value format made obvious?
• Can the field be used safely without errors, regardless of interpretation?

Note: input types that have hyphens (-) as values means that browser does not support that input type.

Google Chrome (52)

Determining the Locale

Setting	Result
HTML language attribute	Nope
Content-Language header	Nope
User language settings	Yep

Chrome uses the browser language, or rather the OS language, to determine the locale. Everything else is ignored.

Error Prevention

Input type	Reveals expected format	Constraint input	Is it safe?
date	Via a placeholder	Numeric only split over three components, and a datepicker	Not for prefilled fields
month	Via a placeholder, but not very clear	Month is based on single-letter keyboard input, year is just numeric	Confusing, but safe
week	Via a placeholder	All numeric over two components	Yep
time	Through component delimiters	All numeric over two components	Yep
date-time	Via a placeholder and component delimiters	Same as a date + time field	Not for prefilled fields
number	Nope	Numeric, symbols and “E” for scientific notation	Nope

Firefox (48)

MDN states:

Firefox uses the following heuristics to determine the locale to validate the user’s input (at least for type=”number”):

• Try the language specified by a lang/xml:lang attribute on the element or any of its parents;
• Try the language specified by any Content-Language HTTP header or
• If none specified, use the browser’s locale.

This sounds promising.

Determining the Locale

Setting	Result
HTML language attribute	Yep
Content-Language header	Yep
User language settings	Yep

Error Prevention

Input type	Reveals expected format	Constraint input	Is it safe?
date	–	–	Nope
month	–	–	Nope
week	–	–	Nope
time	–	–	Nope
date-time	–	–	Nope
number	Nope	Nope	Nope

Perhaps Firefox are still trying to figure out localisation strategies?

Safari (9.1)

Determining the Locale

Setting	Result
HTML language attribute	Nope
Content-Language header	Nope
User language settings	Yep

Error Prevention

Input type	Reveals expected format	Constraint input	Is it safe?
date	–	–	Nope
month	–	–	Nope
week	–	–	Nope
time	–	–	Nope
date-time	–	–	Nope
number	Nope	Nope	Nope

Safari (iOS 8.4)

Determining the Locale

Setting	Result
HTML language attribute	Nope
Content-Language header	Nope
User language settings	Yep

Presumably this is the same of how Safari on OS X works. I expect these two will stay identical, or similar at least.

Error Prevention

Input type	Reveals expected format	Constraint input	Is it safe?
date	Nope	Yes, a multi-select popup	Yep
month	Nope	Yes, a multi-select popup	Yep
week	–	–	Nope
time	Nope	Yes, a multi-select popup	Yep
date-time	Nope	Yes, a multi-select popup	Yep
number	–	Nope	Nope

Interestingly, iOS does support various HTML5 input types. Via a simple multi-select popup, they constrain input, making all possible values valid.

Edge

Determining the Locale

Recently Microsoft claimed that Edge is the first browser that has full HTML5 support. I wonder if that also includes localisation.

Setting	Result
HTML language attribute	Nope
Content-Language header	Nope
User language settings	Inherited from OS

I couldn’t get Edge to render the input fields in any locale but American English. Edge appears to inherit the language settings from Windows.

Error Prevention

Input type	Reveals expected format	Constraint input	Is it safe?
date	Via placeholder	Yes, a multi-select popup	Yep
month	Via placeholder	Yes, a multi-select popup	Yep
week	Via placeholder and component delimiter	Yes, a multi-select popup	Yep
time	Via placeholder and component delimiter	Yes, a multi-select popup	Yep
date-time	Via placeholder and component delimiter	Yes, a multi-select popup	Yep
number	Nope	Nope	Nope

The test pages used for the tests above are available on GitHub.

Conclusion

Although input field localisation is implemented, we developers cannot control it in any browsers except Firefox. Even if you research to figure out whether the user expects the field formatting to use the same locale as the page, or the user’s computer, it’s a bad bet.

Unfortunately, browsers do not make it very clear what the expected value format is either. Some browsers do it reasonably well for some elements, but many of the hints are too vague or not always available to exclude errors.

Luckily, some browsers did understand these issues and made pop-ups that are actually really helpful and annihilate the possibility of invalid input. In these cases, formatting has become irrelevant. I do wonder how this impacts user experience, as some of these are harder to use than their format-dependant siblings.

Now the big question remains: should we use HTML5 input fields with a polyfill, or should we wait for browsers to improve their implementation? HTML5 input elements with a polyfill should be the standard choice. If your product is available in multiple countries, take inventory of what fields you need and how “risky” they are. If for any reason, they may contain invalid input, you may want to consider using other input elements, a text input element with the pattern attribute, or JavaScript.

Frequently Asked Questions about HTML5 Input Elements