#16630: Support for HTML5 input types -----------------------------+------------------------------------ Reporter: jonash | Owner: nobody Type: New feature | Status: new Component: Forms | Version: SVN Severity: Normal | Resolution: Keywords: html5 | Triage Stage: Accepted Has patch: 1 | Needs documentation: 1 Needs tests: 0 | Patch needs improvement: 0 Easy pickings: 0 | UI/UX: 0 -----------------------------+------------------------------------ Changes (by poswald):
* cc: poswald (added) Comment: I have found that wether or not a developer will want the html5 input type="date" or type="number" feature on a given form input depends on several things: - the type of the data - the usage of the data (for example an id number might never be humanized with commas whereas an amount will be) - if the data needs to be localized in a way not allowed by the html5 spec - the capabilities of the user's browser's built-in widgets (iPad and iPod give input type="number" nice numeric keyboards) - if the user's browser's built-in widgets are 'better' than a javascript polyfill widget (type='date' in Safari is currently a simple up/down arrow, hardly enough for most uses) Because the last two of these need to be determined on a per-user or per- request basis the only real solution that solves all of these is a client- side Javascript library. Unfortunately, the last one even rules out a tool like Modernizr since it reports support even when the support is terrible. That being said, some widgets (like input type='search' ) are clear wins today. For some developers, the above won't be issues and they will want html5 input type support right away. If you're going to try to tackle it server-side, the absolutely ideal situation would be a way to allow the developer to switch date and number types on and off on a per-request basis. Second best would be switching them on and off on a per-widget basis which is what you have in this patch. For those troublesome types, the default just needs to be off with a way to switch them on for select data. Perhaps the best approach is to allow the form to pass in the type to override the default of 'text'? Something like this: {{{ #!python class MyForm(forms.ModelForm): date = forms.DateField(label=_('Date'), type='date') num = forms.IntegerField(label=_('Number'), type='number') }}} This way, when browsers get better support for these data types, it is a simple matter of changing the default but developers can still manually override defaults. -- Ticket URL: <https://code.djangoproject.com/ticket/16630#comment:12> 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 post to this group, send email to django-updates@googlegroups.com. To unsubscribe from this group, send email to django-updates+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-updates?hl=en.