The date picker only defaults to today's date if they don't specify a default value.
Tbh I think setting a default value might actually have been a better solution. It's not perfect, but hacking together your own alternative could lead to a number of issues for folks relying on screen readers and other input devices. The `type="date"` gives a lot of semantic meaning that `type="number"` lacks.
If you're gonna ditch it, I'd say at least use an existing external library that's been battle tested for accessibility.
If a default value is set you’re going to have the problem of people skipping the field and submitting the default value instead. What is needed is a way of influencing the picker’s default view into year view with a default year visible, but without actually setting a default value. Only Apple can provide that level of control.
That's not what `defaultValue` does. `defaultValue` is a JS (not HTML) attribute which simply allows you to retrieve the original value set in the HTML. So if you have this HTML:
<input id="foo" value="bar">
Then `document.getElementById('foo').defaultValue` will always return `'bar'`, even if the user has edited the value in the field.
Then yeah I suppose it'd have to be a javascript trick that sets the default value when the calendar is opened or, as GP suggested, something done at the standards or implementation level
You’re talking about slightly different things. You’re right that when the UI opens it’s always going to be on a default date, if you don’t set one it’ll be today.
But if you don’t set one then the value of the HTML element will be null before it’s selected. So if you add a required attribute then you can make sure that your users use the date picker (or leave in frustration after failing to do so) before submitting the form.
If you set a default value using the value attribute, then that becomes both the HTML default value and the UI default. IMO the spec is missing a way to just set the UI default, so that the field is default empty but interacting puts it at a sensible starting point.
What would a default birthdate be? That would span 80+ years. That's not going to work. Any time an input spans ~29k values, you better provide some logarithmic-time searching mechanism. So yes, Safari's date picker is f'ing dumb.
From left to right, that's Chrome desktop, Chrome mobile, Safari desktop, Safari mobile, and Firefox desktop
---
The post specified that the users are mostly senior. Regardless of what they go with clearly 0% of their users benefit from leaving it to default today unless they somehow figured out how to sell smartphones to fetuses
Tbh I think setting a default value might actually have been a better solution. It's not perfect, but hacking together your own alternative could lead to a number of issues for folks relying on screen readers and other input devices. The `type="date"` gives a lot of semantic meaning that `type="number"` lacks.
If you're gonna ditch it, I'd say at least use an existing external library that's been battle tested for accessibility.