The State of HTML5 Input Elements

The State of HTML5 Input Elements

  • 2016-10-12
  • 785

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:

Example where number formatting results in odd input

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.

Datepicker on iOS

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 quesions 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?

The Test Pages

The test pages are available on GitHub.

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

Google Chrome (52)

Determining the Locale

enter image description here

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

Error Prevention

enter image description here

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

enter image description here

Error Prevention

enter image description here
Perhaps Firefox are still trying to figure out localisation strategies?

Safari (9.1)

Determining the Locale

enter image description here

Error Prevention

enter image description here

Safari (iOS 8.4)

Determining the Locale

enter image description here

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

enter image description here

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.

enter image description here

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

enter image description here

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.

Suggest

HTML5 & CSS3 : Landing Pages for Entrepreneurs 2016

Build a Responsive Website with HTML5, CSS3 and Bootstrap 4

Build Responsive Website Using HTML5, CSS3, JS And Bootstrap

Hybrid Mobile App Development with Ionic

Become a Professional Programmer