[antris]

The most straightforward solution I can think of is to split date inputs by context. Create an `<input type="dob">` that is tailored for picking a date of birth from 1900-today. "date" is too vague of a context to create an UX that works well in all the different contexts. It'll always be bad in some contexts, if it's trying to solve all the use cases.

[noduerme]

This. In my form generation library (that I maintain and use for client apps) there are two types of datetime input areas available. They take the same arguments for ranges and single/double dates, with or without time, and at what frequency of time (e.g. hourly, 15 minutes, etc). One wraps a calendar library (daterangepicker) and attaches it to the form; the other generates a responsive text input with placeholders and danger labels. Their outputs are both returned as Moments which can be sanity checked, tested against other constraints and shipped back out as YYYY-MM-DD HH:MM:SS to the database.

[crabmusket]

This would be good, or maybe use type=date and inputmode=dob? As it affects the method of inputting what is ultimately still a date.