How I built a date picker | Hacker News Reader

How I built a date picker

decoding.io

66 pointszsbenke56 comments

Please please please don't do this! This article doesn't even mention ARIA and the result would fail any accessibility audit.

There is really no way to implement this in JS anyway because all major browsers have native date pickers by now: https://caniuse.com/input-datetime

<input type="datetime-local"> is tolerable for simple cases, but you can often do so much better than it: showing extra information in the pickers like disabling days that are not permitted (e.g. appointment calendar on a day nothing’s available), and allowing free-form text entry like “3pm” or “next Thursday”, those sorts of things. As it stands, <input type="datetime-local"> and its kith and kin are very restricted and mildly painful to use, by comparison. Perhaps browsers could improve them and make them more flexible and freeformable, but they haven’t done so yet. There’s a reason why very few sites actually use those date/time input types, and I don’t think it’s just their comparative recentness.

Yes, you do want to be careful about accessibility here, but it’s emphatically not a “please please please don’t do this” situation. Because its essence is just a text box, the accessibility of what’s been made here is probably actually excellent, and if it’s not, it should require only minor tweaks to make it so. You very probably actually don’t want to expose the popup in any way—for what I see, doing literally nothing for accessibility will probably be better in most instances than doing something.

> the accessibility of what’s been made here is probably actually excellent

It's not. The whole thing is in a <table>, there's no ARIA attributes let alone ones that reflect states, and the buttons are...<li>'s?

> doing literally nothing for accessibility will probably be better in most instances than doing something

This is a great example of why that's true. If the author had referenced any of the best practices for this, they wouldn't have ended up with such a bad result.

https://www.w3.org/TR/wai-aria-practices-1.2/examples/combob...

You can add stuff like that, and it’s definitely a legitimate and reasonable approach, but the popup is not functionally necessary, and done fancily even properly stands a fair chance of being just a distraction. If the popup were the only interface then yes, it would be important to optimise accessibility on it, but as it stands I think also it’s a perfectly reasonable option to make the popup entirely inaccessible by keyboard or accessibility tool, and just work with the text box. (This would be paired with things like having Up/Down work to increase/decrease the year/month/date where the cursor is, rather than Up/Down/Left/Right navigating around the calendar table.)

I’d be interested to see what a regular user of accessibility stuff would find of this stuff. I think both approaches are perfectly reasonable, with the don’t-expose-the-popup-at-all side possibly even preferable for some.

This is an unfortunately common attitude, "make the ____ entirely inaccessible by keyboard," and it leads to projects like these.

A11y and web components are well studied, start from the best practices, and if you deviate, have a good reason why that's supported by testing.

In terms of accessible date pickers, I'd refer people to the GOV.UK styleguide which explains what to use when (and by law their stuff needs to be accessible!)

https://design-system.service.gov.uk/patterns/dates/

On Linux at least, the Firefox datepicker is pretty terrible to the point of just being broken. The Chromium one is okay I guess, but with some annoyances. I don't know the status on all the other platforms, but that's why I generally just prefer controlling it myself.

Good to see Safari finally added it nine months ago. Small annoyance, but I remember the inputs' values not being consistent either. Is that still the case?

Is there an interactive demo? I searched but could not find one. It would be very helpful to get a feel for how it works and appears.

Nope. Not that I could find, not without pulling the repo and installing it somewhere. Quite an oversight. I don't want to watch a video, I want to click on the damned thing.

Coincidentally I built one yesterday at well. Opposite approach. As little code as possible.

First of all

    Input type=date

On Android shows a date picker that many users have found confusing to operate. They can't figure out how to select the year. I used to say "not my problem" but it actually was because they still complained.

    Input type=month

Solves that first problem and then a day selector does the rest but that's an unfamiliar paradigm so...

I wanted year/month/day in a way that uses will find easy. One for each then.

There's many existing options and they use a lot of code. I mean just an insane amount. I don't want a boatload of code to select a date in a way that users won't complain.

The browser already knows everything about dates, so we can just ask it how many days are in a month and what the name of the month is.

Leap years, leap seconds, it's all in there. No wheel reinventing necessary

So we have one of our two key lines

    let maxday = new Date(year, month, 0).getDate();

(It'll be further explained at the end.)

2nd part; let's not have an array of month names. Instead, let's ask the browser for what the user calls the months based on their first language:

   Intl.DateTimeFormat(
     navigator.languages[0],
     {month: 'long'})
   .format( new Date(startyear, i) )

So they select the year, then the month, then we use that as a query to find out how many days are in the month by asking the default Date object, already built in.

And all together now https://gist.github.com/kristopolous/d956c148ddcb628d54ec511...

Btw, this is for a product related to driving a car so we aren't dealing with blind users. A lot of accessibility things were skipped

Just an FYI creating the Intl formatters is quite expensive and we ran into perf issues and needed to memorize them (globally in the app)

Debated posting this, but it's memoize, not memorize.

Thanks, need to disable autocorrect...

What would improve my quality of life is if date pickers used some global cookie mechanism to share recent dates between websites. The number of times I'm looking at flights/hotels around the web and have to keep entering the same date on infuriatingly different date pickers is soul destroying.

At least allow a date to be pasted in and have the logic to accept if the user has entered something thats different from what the backend needs but makes sense for the the current date and their locale: "22 feb" "22/02/2022" "22/2" "2/22" etc

That would make a good browser extension. As a cookie, it would allow all kinds of tracking shenanigans unfortunately.

Would improve mine would be intelligent text parsing of dates with feedback.

e.g. : "2 feb" and it says "2 feb, 2022, 6 days from now"

write "3/2/2022" and it refuses to validate, but lets you select "2 feb, 2022" or "3 mar 2022" to replace to continue.

Date pickers are horrendous UX, IMHO for so many reasons. Text is so much better.

There's not an example for us to try out on that page? That's cruel.

I can't find a readily accessible demo, but if I could, the first thing I'd do is check to see if there are two 2:00AM options at the relevant local time DST boundary.

Do people actually use and like date pickers?

As a user, every time I see one, I groan and fight it instead of liking to use it.

But I haven't seen any A/B tests. Does date picker really improve user experience?

Conceptually, it needs to take in account the type of date it handles. The question to ask is “does it matter when in the week or a month a date is selected?” or similar.

Under these considerations, I can say that for a "well known" date, like a birthday, or an expiration date, where the context of the calendar doesn't matter, it's not needed, and probably undesirable. (Under these contexts I would use bare selects/inputs with one for each of YYYY/MM/DD.)

For an appointment, or a time span? Date pickers are useful. “Which days are mondays?” “I want to book from a monday to the friday the next week.” Raw controls won't provide the context to help the user.

I feel the ones you fight against are more than likely those where you already are aware of a precise moment, in the first scenario. The others are more likely to leave no impression if well done.

With that said: Always de-compose the date picker in their discrete parts that a user can use. Make the picker fill these.

Ahhhh that makes sense.

Yes, I hate when I see a date picker for birthday. I don't need to pick a date on birthday!

But when it's meeting or airplane ticket, it makes sense.

So, picker is good when you don't actually know the date yet.

OK, thanks!

Most important thing date picker helps is user doesn't need to understand required input format. Coz there is no standard format across apps and localities.

Sad ISO 8601 noises

There is one, it is a standard, it is a format, it is "an international standard covering the worldwide exchange and communication of date- and time-related data". But not everyone uses it.

They are also useful for date range input. Or if the user needs to work out the date by looking at a calendar which is pretty common if you are doing something like booking a holiday or time off work.

They are nice for hotel and flight bookings to try out different dates, visualize the length of the stay and quickly see what day if the week you are picking.

I think they would be good where additional info can be inlined such as existing events.

But without those advantages I prefer to type it. Especially date of birth!! A year older is another 10px to scroll!

A competent date picker? Sure. One that has doesn't function as expected, even slightly? Then no.

I like date pickers especially for when I need help deciding a date, e.g. when booking a haircut: I don't know exactly what day I want to go in, but I'll know it when I see it.

Date pickers are also useful for ranges of dates (although the UX for these is hit-and-miss), since it helps visualize duration nicely and always makes it easier to pick an end date.

I'm 50/50 when it comes to a date that I know, but usually, I'll prefer a ISO8601 input field for that.

Also, is it internationalized? Many government forms in Japan require Japan's era date, not a Gregorian date

https://en.wikipedia.org/wiki/Japanese_era_name

I just hate when they’re mandatory. Sure, let someone use the picker if they want. I’ll jam in my MMDDYYYY in a second flat.

Every year I get older those DOB selectors take longer to complete.

How do you book flights or hotels then?

I don’t particularly have a string opinion on date picker, but I find myself typing in dates when possible. Particularly when entering something like a birthday, so I don’t have to navigate to the prior century first.

There are date/time pickers that let you type in the input field if you click a little area with a calendar icon next to it. Our date/time fields are like that.

Stimulus really seems like a boat anchor in the example. An ugly method missing clone to figure out which property to handle? Yetch.

Gets more complicated as you need things like like min date, max date and same for time of day, exclusion blocks of time, Start of week day, touch friendly, accessibility friendly

I know this is off-topic, but date pickers that don't let you type the date are so infuriating to me.

That's not off topic. It's covered in the article - the component enables text entry, and two-way data binding means the calendar widget updates as you type.

Why does every website in the world insist on having its own massively over-engineered GUI to solve this problem?

Use a text entry field, validate it with a regex, and have an error message that says "YYYY-MM-DD plz" if it fails the regex.

You call it over-engineering, I call it good UI. I want to enter the date my way, and the computer can figure out the format. If I type 3 Nov it should know I mean 11 3 2022. Computers are good like that, and a half decent date parser is trivial to write.

Nothing drives me crazy like a credit card number field that tells _me_ to remove the spaces or hyphens from the number. Like what, the computer can't do that for me?

Yes to your first suggestion, ew disgusting to your second suggestion.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

I mostly gave up on date pickers, I prefer entering a datetime as text and if it can automatically figure out the format I'm using then it's godsend. Clicking tiny buttons with unknown behavior takes way too much time

But why build a date picker?

Because most of them lack time, and you need time to store dates in different time zones? This one lacks seconds for instance. Our date/time filelds are in ISO8601 (concatenated with space) so we also need seconds.

> Monday is anchored to 0, Tuesday to 1, Wednesday to 2, etc.

Sunday is actually the first day of the week (i.e. column index = 0) in almost every calendar I've used. Perhaps this varies by culture/locale?

"Monday is the first day of the week according to the international standard ISO 8601, but in the US, Canada, and Japan, it's counted as the second day of the week." - https://www.timeanddate.com/calendar/days/monday.html

I've always thought of Monday as the first day of the week. It's the day that starts the workweek (and school week) and Sunday is part of the weekend.

I find it utterly baffling that anyone out there believes Sunday is the first day of the week. It's literally the last day of the weekend.

Unrelated, but not much, see how Office/Excel WEEKDAY has parameters for the starting day (and numbering starting from 0 or from 1):

https://support.microsoft.com/en-us/office/weekday-function-...

Yes it does. It's a very US thing.

Well, Monday is in most of Europe AFAIK?

It does

Why does a simple date picker demo require using SQLite ???

As long as I can still enter the date manually in the textfield, I don’t mind a picker.

It is very user unfriendly to choose a date of something like a birthdate with a picker.

Honestly, the best way to input dates is to have 3 fields (with the labels of y, m, d) and let the user INPUT the date.

Which tool or website are you using to write the article in such a cleaner way? Could you please suggest? Thanks

It's WordPress with a custom built theme.

It's WordPress with a custom(ized) theme.

Reply on news.ycombinator.com