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
The project itself has been deprecated
This is an up-to-date guide demonstrating why the old deprecated Pikaday JavaScript Datepicker is no longer needed.
Usability doesn't matter when there's an established behavior. Users get used to how it works, and then differences cause stumbling blocks.
Use the native date pickers.
If you're fine with loosing most of your customers because they can't use your website, then go ahead with native date pickers. But I'm not going to ask my customers to scroll on a list of numbers on their iPhone or try to pinpoint a microscopic calendar on their computer to pick a date. User comes first. Developer comes last.
I tried some of the inputs and found that they worked well for initial input, but editing inputs didn't (e.g. the masked date input cursor just jumps over previous decimals, when typing a new number)
I made a reproduction video and tried to report it to the Pikaday issue tracker after which I found out it's deprecated.
Going back, and comparing the readme with the page, does show that the post uses native inputs. ... I feel that could have been more explicit; in this post I expected Pikaday to have the option to use native pickers with some component styling.