What would be the specific difference between all of those?
For many use cases you described, the primary UX flow should probably not have a date picker at all, but rather the date would be selected implicitly through other user actions: i.e. to add an appointment, you might start with a full-page calendar view and click on the appropriate day; for prices you'll probably have "next day"/"previous day" buttons built into the page.
But those UX flows are orthogonal to the flows that actually do use a date picker, IMO.
* For DOB, what you typically need looks more like three text boxes. That said, the text boxes need to be able to work together in terms of validation - the 31st of February 2015 is not a valid date! This is why it's better to think of this as a single form control with multiple input fields. Alternatively, I want something where I can pick the year first, but this typically leads to lots of scrolling.
* For adding an appointment, I probably want something closest to the conventional date picker, but even then, if I'm making an appointment for a group, I might still want additional information about when people are available displayed directly in the calendar view as I'm choosing a date.
* If I want to browse for the cheapest date, then I want a way of seeing all the dates available and the prices of those dates at the same time, meaning a relatively rich date picker control. If all I have is "next day"/"previous day", then I need to manually click around a lot to get good deals.
* If I want to select a range of dates, then I want a single control that allows me to select that range immediately, not having to open a "start" field and an "end" field separately. I also probably want multiple months visible, depending on how long my range is, so I can see the whole range at a glance without having to click back and forth between months.
* This is more subtle, but a hotel visit requires a range of dates, but a flight to and from the hotel requires two discrete dates, which might potentially be indicated with yet another date picker variant.
These are all flows that require me to pick a date, most of them from a calendar, and all of them could arguably be considered important enough for a native element (in the sense that I use all of these elements in my day-to-day web browsing). But they're all very different, require different interactions and content, and have subtly different purposes.
Thank you for this perspective. I despise when a website makes me pick by birthday in a typical date picker.
Maybe we are lacking vocabulary for these different types of date widgets. I've never heard anyone take about an historical date picker as a separate concept.
At that point, you're creating and writing a different flavor of date picker -- and in static HTML land, there is no clean way to update page content dynamically based on user input, without some kind of JavaScript library interacting with those elements (talking to the UI) and coordinating input data, displaying new derived data/info based on those selections with snappy, accurate feedback.
There are hundreds of ways to support this using JavaScript because the community has cleverly come up with many different flavors of view handling to suit different mental models and preferences. What could be better?
For many use cases you described, the primary UX flow should probably not have a date picker at all, but rather the date would be selected implicitly through other user actions: i.e. to add an appointment, you might start with a full-page calendar view and click on the appropriate day; for prices you'll probably have "next day"/"previous day" buttons built into the page.
But those UX flows are orthogonal to the flows that actually do use a date picker, IMO.