[abanana]

I think your point is just emphasizing how bad these native datepickers are. They are specifically used by the browsers for <input type="date">. Their purpose is to enter a date. That's why their use in this way is absolutely standard (far more so than the term "calendar picker" as far as I'm aware. The user's not choosing a calendar, they're choosing a date). That doesn't mean the choice of input method can't be improved, but highlighting it as a pet peeve won't make it happen at scale. What do you suggest instead?

The answer shouldn't be "create something custom for entering dates that don't happen to be in the current year", it should be "fix the datepicker so it's fit for purpose".

[badestrand]

I am so glad that so many people in this thread confirm how bad the native date pickers are; i thought I was alone.

Just picking the year is so difficult already on both Android and iOS as well as desktop Chrome, so a custom widget is immediately 100x better.

Yes, in theory it would be best to display the native picker because in theory it has a great UX, but in practice the native browsers' implementations are mostly just really, really bad, for whatever reason.

That's what I really dislike about the linked article - it doesn't even check the native implementations for their quality but just argues as if they are great.

[padjo]

Ideally there would be an input type for this, month comes close to the correct UI on iOS but has lots of problems. I don’t think the calendar picker style will ever work well for entering birthdays and such, so yeah the answer is build your own thing or use a library.