This is cool, but the last two just awful. The most annoying part of typing in credit card info is getting into the flow of typing in numbers from a card, then having to switch to "number to month name, then scan a dropdown", then to "convert two to four digit year and scan another dropdown of seemingly random length", then back to typing numbers for the CVC. On a computer, you need to switch between keyboard and mouse and back, on mobile your keyboard open and closes, reflowing the whole window and moving elements around a handful of times.
In contrast to a "just type it" date picker (as in example 4) and staying in "just typing numbers" mode the whole time.
> Travel booking often has a fixed schedule with limited time options, such as every 15 minutes. Relative dates like “Today” and “Tomorrow” can be easier to understand.
Except when you're booking a flight and you're not sure whether "today" is based on your local time, the server's local time, or GMT. (I often book flights right about midnight and find words like "today" and "tomorrow" to be completely confusing.)
Montreal public transit times used to be on some kind of like, 28-hour clock. Bus times after midnight would be labelled 27:30 or something. Suuuper confusing. It sounds so bizarre in fact, that I'm doubting my memory a bit, but I'm certain it was like that (say around 2006 or so).
And it is the right thing to do as otherwise the question to which day a train belongs will be confusing. Just take it %24hours before intersecting trains.
It is also how I personally record time spans. It makes it much easier as you do not need to deal with the case where the start is larger than the end time and you can only have a single date field.
I've seen this in Japan as well. A store that's open from, let's say, 8am to 1am will actually advertise itself as being open from 8am to 25pm. I guess the perception is that it's confusing to have a range where the smaller number comes before the bigger number.
From what I've learned, be as explicit as possible when users enter dates.
We had to change our date of birth field in the user sign-up to three separate "Month Name","Day" and "Year" drop downs, since so many people made mistakes (fat finger/ swap month and day) from the "MM/DD/YYYY" field, and would then send support ticket to update it.
For specific dates, I prefer 3 dropdowns with explicit strings for months. So the dropdowns would be "7", "January","2026" etc instead of 01/07/2026 or 07/01/2026 ensuring there is no confusion.
My take is that Date, Time and DateTime pickers are not enough. I want month pickers. Week pickers, custom interval pickers and then some. I really dislike how limited the selection of native form elements is.
Not just Firefox. Safari doesn't have it either. Not usable in a professional context.
I've been following the bugzilla issue for it for years now but there hasn't been any real progress on it. I don't think it'll happen until we can get it to an interop.[0] Speaking of which, interop 2026 is still taking suggestions[1] and I don't see any proposal for these inputs
The context of the date being chosen should guide you to the appropriate picker.
For example, for a dinner reservation, a calendar can be useful to explore availability on weekends. But if I have to enter my birthdate, then it’s quicker to enter it numerically. I don’t need to consider other dates and the day of the week is irrelevant.
When all websites respect their settings and they don't like what the websites do, they will search "how do I change X...", which would point them to the browser settings. If no website respect them, they won't bother. Also these settings come from the OS, which asked the user on install what e.g. date format he wants to use.
They are wrong. Most OS native date pickers are very bad from a usability perspective. A javascript date picker fixes these issues, and allows more functions.
And why are they arguing against their own product? Even making up bogus claims that using js date pickers would be illegal in Europe?
> We’ve decided to archive the Pikaday repository on GitHub. The project has not been actively maintained for years.
> Pikaday was started before <input type="date"> was supported in browsers and before custom elements and component frameworks. Pikaday is probably not the right choice today.
> Pikaday was started before <input type="date"> was supported in browsers and before custom elements and component frameworks. Pikaday is probably not the right choice today
This is cool, but the last two just awful. The most annoying part of typing in credit card info is getting into the flow of typing in numbers from a card, then having to switch to "number to month name, then scan a dropdown", then to "convert two to four digit year and scan another dropdown of seemingly random length", then back to typing numbers for the CVC. On a computer, you need to switch between keyboard and mouse and back, on mobile your keyboard open and closes, reflowing the whole window and moving elements around a handful of times.
In contrast to a "just type it" date picker (as in example 4) and staying in "just typing numbers" mode the whole time.
> Travel booking often has a fixed schedule with limited time options, such as every 15 minutes. Relative dates like “Today” and “Tomorrow” can be easier to understand.
Except when you're booking a flight and you're not sure whether "today" is based on your local time, the server's local time, or GMT. (I often book flights right about midnight and find words like "today" and "tomorrow" to be completely confusing.)
Montreal public transit times used to be on some kind of like, 28-hour clock. Bus times after midnight would be labelled 27:30 or something. Suuuper confusing. It sounds so bizarre in fact, that I'm doubting my memory a bit, but I'm certain it was like that (say around 2006 or so).
This is actually how GTFS (a standard format for public transit data) works: https://gtfs.org/documentation/schedule/reference/#stop_time... . Especially sleeper trains can get weird with 30+ hours. But I don't think it's wise to show that to the user
And it is the right thing to do as otherwise the question to which day a train belongs will be confusing. Just take it %24hours before intersecting trains.
It is also how I personally record time spans. It makes it much easier as you do not need to deal with the case where the start is larger than the end time and you can only have a single date field.
I've seen this in Japan as well. A store that's open from, let's say, 8am to 1am will actually advertise itself as being open from 8am to 25pm. I guess the perception is that it's confusing to have a range where the smaller number comes before the bigger number.
From what I've learned, be as explicit as possible when users enter dates.
We had to change our date of birth field in the user sign-up to three separate "Month Name","Day" and "Year" drop downs, since so many people made mistakes (fat finger/ swap month and day) from the "MM/DD/YYYY" field, and would then send support ticket to update it.
For specific dates, I prefer 3 dropdowns with explicit strings for months. So the dropdowns would be "7", "January","2026" etc instead of 01/07/2026 or 07/01/2026 ensuring there is no confusion.
My take is that Date, Time and DateTime pickers are not enough. I want month pickers. Week pickers, custom interval pickers and then some. I really dislike how limited the selection of native form elements is.
Do you think there is anything missing from <input type="week"> or <input type="month"> other than Firefox support?
Not just Firefox. Safari doesn't have it either. Not usable in a professional context.
I've been following the bugzilla issue for it for years now but there hasn't been any real progress on it. I don't think it'll happen until we can get it to an interop.[0] Speaking of which, interop 2026 is still taking suggestions[1] and I don't see any proposal for these inputs
[0] https://wpt.fyi/interop-2025
[1] https://github.com/web-platform-tests/interop/issues?q=is%3A...
The context of the date being chosen should guide you to the appropriate picker.
For example, for a dinner reservation, a calendar can be useful to explore availability on weekends. But if I have to enter my birthdate, then it’s quicker to enter it numerically. I don’t need to consider other dates and the day of the week is irrelevant.
Context: https://dbushell.com/2025/11/10/pikaday
Great writeup, I think it'd be really helpful if this could be expanded to include handling timezones as well.
Does it have options like multiple date pickups, pickups for a particular month only, and a yearly pickup?
Native datepickers fall apart when you need to handle different date formats as user preferences (not as browser default)
The browser, called the User Agent (UA), IS the program the user uses to interact with a website according to his preferences.
Maybe. How many users change the defaults, or even know it’s an option?
When all websites respect their settings and they don't like what the websites do, they will search "how do I change X...", which would point them to the browser settings. If no website respect them, they won't bother. Also these settings come from the OS, which asked the user on install what e.g. date format he wants to use.
I wish there's a native calendly style time slot picker too.
They are wrong. Most OS native date pickers are very bad from a usability perspective. A javascript date picker fixes these issues, and allows more functions.
And why are they arguing against their own product? Even making up bogus claims that using js date pickers would be illegal in Europe?
https://github.com/Pikaday/Pikaday
> We’ve decided to archive the Pikaday repository on GitHub. The project has not been actively maintained for years.
> Pikaday was started before <input type="date"> was supported in browsers and before custom elements and component frameworks. Pikaday is probably not the right choice today.
From the GitHub project:
> Pikaday was started before <input type="date"> was supported in browsers and before custom elements and component frameworks. Pikaday is probably not the right choice today
The project itself has been deprecated
This should be higher up. Posting a deprecated library with this title is an interesting choice.
Did you click on the OP? This whole post is about using native date pickers. The very first words are:
> Who needs a JavaScript date picker?
> The answer, in most cases, is nobody!
You're all getting a little confused!
This is an up-to-date guide demonstrating why the old deprecated Pikaday JavaScript Datepicker is no longer needed.