#37083: Add opt-in HTML5 date/time input types for form widgets
-------------------------------------+-------------------------------------
Reporter: Denny Biasiolli | Owner: (none)
Type: | Status: closed
Cleanup/optimization |
Component: Forms | Version: 6.0
Severity: Normal | Resolution: duplicate
Keywords: datetime, date, | Triage Stage:
time, inputs, admin, forms | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 1
-------------------------------------+-------------------------------------
Changes (by Jacob Walls):
* resolution: => duplicate
* status: new => closed
Old description:
> == Summary
>
> Django's `DateInput`, `TimeInput`, and `DateTimeInput` widgets currently
> render `<input type="text">` unconditionally.
> Modern browsers provide native date and time pickers via `<input
> type="date">`, `<input type="time">`, which offer a significantly better
> user experience—especially on mobile devices—without requiring any
> JavaScript.
>
> The Django admin's `vDateField` and `vTimeField` rely on custom
> JavaScript (`DateTimeShortcuts.js`) to provide calendar and clock popups.
> While functional, these are less accessible and less consistent across
> platforms than the native browser pickers.
>
> My idea is to add a new global setting, `USE_HTML5_DATE_INPUT`, that when
> set to `True`, switches these widgets to their HTML5 counterparts on an
> opt-in basis.
>
> The end goal it to go back on this ticket
> (https://code.djangoproject.com/ticket/29822) after (if) the current one
> gets approved/merged.
>
> == Motivation
>
> - **Better mobile UX**: Native pickers are touch-friendly and consistent
> with OS conventions. The current JS-based popups are difficult to use on
> small screens.
> - **Accessibility**: Browser-native pickers are built with accessibility
> in mind (keyboard navigation, screen reader support) out of the box.
> - **Reduced JS overhead**: When native pickers are used, the admin's
> `calendar.js` and `DateTimeShortcuts.js` become unnecessary for date/time
> fields.
> - **Gradual rollout**: Defaulting to `False` ensures zero breaking
> changes. Projects can opt in when ready and validate behavior before
> committing.
New description:
== Summary
Django's `DateInput`, `TimeInput`, and `DateTimeInput` widgets currently
render `<input type="text">` unconditionally.
Modern browsers provide native date and time pickers via `<input
type="date">`, `<input type="time">`, which offer a significantly better
user experience—especially on mobile devices—without requiring any
JavaScript.
The Django admin's `vDateField` and `vTimeField` rely on custom JavaScript
(`DateTimeShortcuts.js`) to provide calendar and clock popups. While
functional, these are less accessible and less consistent across platforms
than the native browser pickers.
My idea is to add a new global setting, `USE_HTML5_DATE_INPUT`, that when
set to `True`, switches these widgets to their HTML5 counterparts on an
opt-in basis.
The end goal it to go back on this ticket
(https://code.djangoproject.com/ticket/29822) after (if) the current one
gets approved/merged.
== Motivation
- **Better mobile UX**: Native pickers are touch-friendly and consistent
with OS conventions. The current JS-based popups are difficult to use on
small screens.
- **Accessibility**: Browser-native pickers are built with accessibility
in mind (keyboard navigation, screen reader support) out of the box.
- **Reduced JS overhead**: When native pickers are used, the admin's
`calendar.js` and `DateTimeShortcuts.js` become unnecessary for date/time
fields.
- **Gradual rollout**: Defaulting to `False` ensures zero breaking
changes. Projects can opt in when ready and validate behavior before
committing.
--
Comment:
Hi there, thanks for this. This has been discussed in a few places. (I see
you've participated in some!)
First, we just merged a documentation improvement in #33113.
Some more recent updates in [https://forum.djangoproject.com/t/adding-
searchinput-widget/32496/12 this forum thread] and
[https://groups.google.com/g/django-developers/c/wp-
pnzcB25o/m/D5gEOzPIAQAJ this mailing list thread].
Quoting from the first link:
> The consensus has been that each time it’s been looked at the cross
browser support wasn’t there, and we weren’t sure about handling
migrations for folks who’ve already done other things. But pending the
first improving, likely the second could be addressed. (So question is
largely, when, if ever, is it good enough? E.g. Is input type="date" ready
for use in accessible websites? - Hassell Inclusion)
So, I'll mark this as a duplicate of #21470 and #33100. However if you
have an interest in pursuing this, I would suggest a forum thread (focused
on date/time) to address these points:
- demonstrate that cross-browser support is ready
- demonstrate that accessibility will be good enough, taking into account
the improvements we just made to the existing widgets in #36459 and
#36458.
- mention touch-friendly aspect
- backwards-compatibility concerns, especially for less common formats
- respond to any points from those earlier threads
If you can refresh this discussion, that will be a huge help. Once there
is consensus to do something we can reopen the ticket. Thanks.
--
Ticket URL: <https://code.djangoproject.com/ticket/37083#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/0107019df858fda1-cb6c2700-30c5-4988-9156-b84f46cac2c8-000000%40eu-central-1.amazonses.com.
