I'm writing a CSS book

JavaScript archives Compatibility Thidrekssaga QuirksBlog Donations CSS book Politics Mobile About COH

contact

Making input type=date complicated

Everyone who’s ever messed around with dates knows that they are terribly user-hostile — not only for software developers, but also for users. True, users will be able to tell you their date of birth or today’s date without trouble, but ask them to fill them out in a web form and they will encounter problems.

Month first, day first, or year first? And what about slashes, dashes, and other separators? Usually the website engineer has a strong personal preference and enforces it religiously upon unsuspecting users with stern and incomprehensible error messages in a lurid shade of red that are too tiny for anyone over 25 to read.

(This article was originally published on Samsung Internet’s Medium channel. Since I do not believe Medium will survive in the long run I re-publish it here.)

input type="date"

In theory, there’s a solution to this problem: <input type=”date”>. It offers a special interface for picking dates, and it enforces a standard format for the value that’s sent to the server. Better still, the mobile browsers support it. In fact, this input type was created specifically with mobile browsers in mind, as we’ll see shortly.

On desktop support is more patchy. Chrome and Edge each support their own version, but Firefox and Safari don’t — even though their mobile versions do.

Here’s how it works — if it works at all in your browser:

It will surprise no one that there are still some browser incompatibilities. Nonetheless, browsers agree on the dual purpose of this type:

1. Offer the user a convenient interface for entering dates.
2. Send predictable output to the server. All browsers I tested return a string in the format yyyy-mm-dd.

The return value does not pose any problems I’m aware of, so we will ignore it. Instead, we’re going to talk about the interfaces browsers create. There are some problems here; and web developers imagine even more problems.

Over at HTML5 Doctor Ian Devlin gave a good overview of some technical issues with date pickers. Note, though, that the WebKit/Blink bug he notes has been fixed, and that I disagree with his assessment of the UI of Microsoft’s date picker.

You should be aware that Chrome’s calendar widget is stylable if you use the correct pseudo-elements. Also, it seems the date pickers’ accessibility is good enough, although there are a few issues with related types such as time and week.

Browser comparison — mobile

Let’s continue with some good news. Just about all mobile browsers, including Safari, Chrome, and Firefox, support the date-related types, and all of them offer a nice native date picker widget. Below is the Samsung Internet version, but the other mobile browsers have pretty much the same interface. You can find screenshots for all types for six mobile browsers here.

If you feel that this date picker looks a lot like the system date picker that you use for setting dates and times on your phone, hey, that’s not a coincidence. In fact, type="date" was created exactly so that mobile browsers could outsource date picking to native components. The idea behind that is that users will already be familiar with it, and that they’re reasonably well suited to the mobile touchscreen environment.

Issues

That doesn’t mean this interface is perfect. The UK Government Digital Services does not recommend using these native widgets because of problems they found during user tests. Most importantly, filling out your date of birth may require a lot of scrolling: the date picker starts at the current year, and the older you are, the more you have to scroll back.

As a result the GDS recommends using three separate form fields for day, month, and year, not offer any other interface, and being liberal in what the server accepts. I definitely agree with that last bit of advice, and must admit that scrolling back to your year of birth may be annoying.

The date-of-birth problem could be partially solved by setting the default value of the date field to 18 years before the current date. It is reasonable to assume that just about every visitor of a government website is over 18, so setting the date would save everyone some scrolling. Still, this is just a little extra bit of help, and not a fundamental solution to the problem.

Despite these valid concerns, we should realise that many sites have different requirements. Flight and hotel booking sites, for instance, want to know your date of arrival and departure, and they are usually a few months into the future at most. For these sites there is much less of a reason to avoid <input type=”date”>.

Browser comparison — desktop

So that’s the situation on the mobile side. On the desktop side things are murkier; mostly because Chrome and Edge each support their own interface while Safari does not support <input type=”date”> at all. (At the time of writing, mid January 2017, Firefox support hadn’t yet landed. This article doesn’t treat the Firefox desktop implementation.)

Edge

Let’s start with Edge. Its date picker resembles the mobile date pickers very much — even on non-touchscreen desktop. This re-use of a touchscreen-friendly component is not surprising. Microsoft is placing a major corporate bet on hybrid desktop/tablet devices, and therefore Edge must always support touch interfaces: the user may need it.

Edge managed to make the touchscreen widget fairly user-friendly with just keyboard and mouse: mouse works, obviously, but so do the arrow keys and the scroll wheel if you have one. This is what Edge does on a non-touchscreen device (credit: James Sheasby Thomas):

Thus, while you can quibble about the idea of using the mobile widget at all on desktop, there’s no doubt that if you must use it, you should use it the Edge way.

Chrome

Chrome desktop does something quite different by using a traditional calendar-like widget.

Its usage is very different from the Edge/mobile ones: either you use the keyboard to directly fill out a date in the field (which is fairly intuitive), or you just pick a date from the calendar-like interface.

Personally I’d say that picking another year is slightly more difficult than in the Edge/mobile interface, since it requires two steps: first click on the month, and then figure out that you can scroll up or down in order to see past or future years. How many users will figure that out?

Still, it’s true that people can just fill out a year in the form field itself. That works fine, and it’s fully keyboard-accessible.

So all in all the Chrome widget is perfectly suited to the desktop environment. However, if we were to port it to mobile it would start to show signs of strain. The widget is simply too small for use on mobile screens, and while zooming would help it’s not ideal. Besides, will the keyboard accessibility of the field itself remain in place?

But wait. I just said that all mobile browsers, including Chrome for Android, have mobile date pickers, right? So why is the behaviour of the desktop widget on mobile important? You’ll find out shortly.

Custom widgets

What is a poor web developer to do with this incompatibility soup? First things first: we should get Safari desktop on board by using a custom widget. Here’s a bunch. In order to know whether to use it you’re going to need some support detection for <input type=”date”>. That’s easy as well.

So now we have a situation where Safari desktop uses a custom widget of our choice, while all other browsers use their native date pickers. What’s wrong with this state of affairs?

Nothing. As far as I can see, this situation is close to perfect, unless you decide to follow the GDS advice and not use a date picker widget at all.

But web developers wouldn’t be web developers if we didn’t find a way to marvellously complicate an otherwise straightforward situation. Why keep it simple if we can make it very complex indeed?

A while back I asked about usage of type="date", or good reasons not to use them, and the reactions were pretty unanimous: we can’t use them because browser implementations differ too much. Custom widgets all the way down are the answer, even if the browser has a native date picker. This reaction sums it up:

On mobile date fields look/work great but not so much on desktop, so if you have to add widget for 1 it is easier to use for all.

I disagree. I disagree strongly. In fact, I disagree so strongly that I decided to write this article.

Conservatism

I think we’ve run into a wall of web developer conservatism here, and I think that it’s at least partly unwarranted. The unspoken assumption is, that your site must look and work exactly the same on all types of devices. Even though we know that that is nonsense, we keep falling for it.

According to these (most?) web developers, the optimum solution is to create a single custom widget and use it for all browsers, regardless of what it supports or doesn’t support natively.

I discovered something odd during the research for this article. Compare the date widgets I linked to earlier to this list of jQuery time pickers. You’ll see that, where some time pickers use the mobile interface as a starting point, none of the date pickers do so.

Why this difference? I don’t know, but I seriously doubt there’s any technical or UX reason. I think it’s sheer conservatism caused by the fact that date pickers have always looked like calendar widgets.

So the unitary custom widget that we obviously have to use must be a desktop-centric calendar widget because we should only pay attention to the desktop. Also, we must force our users to download some extra JavaScript. (Not that the payload of a calendar widget is huge, but no extra script is a lot better than a small, unnecessary script.)

Let’s not mince words: these calendar widgets are just wrong on mobile — not because they don’t work, but because a better, cheaper solution is available.

What to do

Thus we have seen that Chrome on desktop uses a calendar widget for <input type=”date”>, while Edge on desktop and all mobile browsers use a touch-friendly interface. Although there are valid issues with both widgets, many mobile users, in particular, would benefit from the use of their native date pickers in other situations.

The only real argument against using native date pickers remains that it can be hard to select your date of birth from a long, long list of years. This problem only appears in fairly specific websites, though — notably government websites.

I start to feel that Apple’s and Mozilla’s refusal to make <input type=”date”> available on desktop is the correct response. Just detect if type="date" is supported (and it is on every mobile browser), and add a desktop-centric calendar widget if it is not.

But that is not to be. Web developers insist on using a single custom widget for all use cases in order to make their websites look the same in all browsers. Again, mobile users in particular could be seriously inconvenienced by these custom widgets, since they’re all based on an interface that is sub-optimal for mobile and/or touchscreen.

Quite apart from the UX inconvenience, there is a danger as well. Currently the Chrome status page reports that less than 0.01% of the Chrome page loads result in an <input type=”date”> being generated. Although many pages don’t need a date picker, this is still a very low number — and we now understand why that number is so low. The Chrome status page warns that features that are used so little are in danger of removal — though I wonder if that would mean desktop Chrome only or also mobile Chrome.

I think it’s time that we trust browser vendors a bit more. The days of useless features for the sake of having a longer feature list are long gone. Nowadays, browser vendors try to add features that are actually useful for users, and are actually implemented by web developers. If a browser says it supports <input type=”date”>, you should trust it to deliver a decent experience to its users. If it says it does not, and only in that case, you should use a custom widget instead.