#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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
