Add opt-in HTML5 date/time input types for form widgets

[Denny Biasiolli]

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.

[Jacob Walls]

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 ​this forum thread and ​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.