#16304 closed New feature (wontfix)
Add HTML5 'placeholder' attribute support to form fields.
Reported by: | Owned by: | Javi Manzano | |
---|---|---|---|
Component: | Forms | Version: | dev |
Severity: | Normal | Keywords: | forms, placeholder, html5 |
Cc: | Simon Charette, Kushagra Sinha, Andy Baker, lrekucki@…, claire12.reynaud@…, javi.manzano.oller@…, martmatwarne | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | yes | UI/UX: | yes |
Description (last modified by )
HTML5 introduces a 'placeholder' attribute to form inputs, providing a text hint which disappears when the user highlights it, which greatly improves the UX of a page.
To do this in Django currently, you have to do something like:
comment = forms.CharField(max_length=200, widget=forms.TextInput({ "placeholder": "Text!"}))
However, to do this with a ModelForm is much more complicated: http://bitkickers.blogspot.com/2010/09/django-html5-input-placeholders.html
I suggest that there should be an easier way to set placeholder text in form fields and model form fields:
comment = forms.CharField(max_length=200, placeholder="Text!")
(This would also be a good starting point for other new HTML5 input elements, such as 'required' and 'email', but those should be separate tickets. The code would be very similar though.)
What do you think?
Attachments (3)
Change History (27)
comment:1 by , 13 years ago
Needs documentation: | set |
---|---|
Needs tests: | set |
Triage Stage: | Unreviewed → Accepted |
Version: | 1.3 → SVN |
comment:2 by , 13 years ago
Summary: | Forms Need HTML5 'placeholder' attribute → Add HTML5 'placeholder' attribute support to form fields. |
---|
comment:3 by , 13 years ago
I think this ticket needs to be coordinated with the form rendering GSOC as a number of changes are being made in this area. Thus you may want to add it to the discussion on the mailing list: https://groups.google.com/d/topic/django-developers/N5EVJhb9la4/discussion
comment:4 by , 13 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
by , 13 years ago
Attachment: | placeholder.patch added |
---|
Patch for adding placeholder attribute on CharField class
by , 13 years ago
Attachment: | 16304.patch added |
---|
Adds placeholder attribute functionality to Model forms and normal forms. Has docs. Does not have tests
comment:5 by , 13 years ago
Cc: | added |
---|---|
Has patch: | set |
Needs documentation: | unset |
Owner: | changed from | to
Patch needs improvement: | set |
Status: | assigned → new |
I have added the said functionality to both model forms and normal forms, in 16304.patch.
However, I suggest to club this ticket with a bigger undertaking of making Django HTML5 aware.
by , 13 years ago
Attachment: | 16304_v2.patch added |
---|
Adds placeholder attribute functionality to forms. Has docs. Has tests.
comment:6 by , 13 years ago
Needs tests: | unset |
---|---|
Patch needs improvement: | unset |
Status: | new → assigned |
Based on the discussions on dev mailing list, I have removed placeholder attribute from ModelForms.
The submitted patch adds a placeholder attribute to Forms. ModelForms will have to be manually overridden to add a placeholder attribute. Has tests and documentation.
comment:7 by , 12 years ago
Cc: | added |
---|
comment:8 by , 12 years ago
Any blockers for landing it in the master? It looks like it is done but not merged for some reason.
It is really needed and useful feature, it improves user experience without tons of workarounds.
Just to note -- all major browsers already support it for more than a year:
browser: Firefox Safari Chrome Opera IE iPhone Android version: 4.0+ 4.0+ 4.0+ 11.0+ 10.0+ 4.0+ 2.1+
comment:9 by , 12 years ago
Description: | modified (diff) |
---|---|
Patch needs improvement: | set |
Is there any reason why this is added only to CharField
? placeholder
is more of a widget thing, so it shouldn't matter on what type of field I define it as long as I use a widget that can render it. placeholder
is also legal on <textarea>
not only variations of <input type="...">
.
comment:10 by , 12 years ago
Cc: | added |
---|
comment:11 by , 12 years ago
Cc: | added |
---|
comment:12 by , 12 years ago
Owner: | changed from | to
---|
comment:13 by , 12 years ago
Cc: | added |
---|---|
Owner: | changed from | to
comment:14 by , 12 years ago
Cc: | added |
---|
comment:15 by , 12 years ago
Github patch. https://github.com/django/django/pull/1111/files
Added to CharField, but applied in all input boxes and textarea.
comment:16 by , 12 years ago
Patch needs improvement: | unset |
---|
comment:18 by , 12 years ago
Cc: | added |
---|
IMHO adding this attribute at the field level breaks the form and widget abstraction contract since placeholder
is exclusively UI related and has nothing to do with data conversion which is what form fields are made for.
While some can argue help_text
is also UI related (and can be specified at the ORM level) it's not entirely bound to input directives and should be used as a data introspection reference (e.g. #9321 is a really bad use of help_text
).
Specifying a placeholder for a model form field is also quite easy:
class MyModelForm(forms.ModelForm): class Meta: model = MyModel widgets = { 'email': forms.TextInput({'placeholder': 'address@domain.com'}) }
I'm slightly tempted to wontfix this ticket.
comment:19 by , 12 years ago
You got a point there. When I picked this ticket I could see some good things about getting this enhancement done, but after I started digging into the code I think I lost part of my conviction.
Feel free to wontfix the ticket.
comment:20 by , 12 years ago
While I agree (see comment:9), I think it would be good to have a way to specify this without having to repeat the whole widget definition. I'm not proposing to implement anything like #17924, but maybe we could extend the set of valid inputs for the widget
attribute to a mapping, i.e.:
comment = forms.CharField(max_length=200, widget={"placeholder": "Text!"})
comment:21 by , 12 years ago
I like your approach, lrekucki. As the placeholder option is UI/widget related, this looks much better solution to me.
I'll give it a try.
comment:22 by , 12 years ago
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
While I also think introducing a way of specifying widget attributes without having to repeat the whole widget definition would be greatly useful I'm a bit concerned about the proposed solution, mainly from backward compatibility point of view.
At first I thought adding a new widget_attr
kwarg to Field
could work but it leaves ModelForm
and its Meta.widgets
overrides behind.
I definitely thinks your suggested approach is worth investigating since I've also been frustrated by the need to declare a whole widget to add a single class
or data-*
attribute in the past.
However this whole discussion should really be moved to another ticket. I'll wontfix this one and look forward a to a new one based on the previous discussion.
follow-up: 24 comment:23 by , 10 years ago
@charettes - Maybe this is something that can be fixed using a templatetag. The nature of class and placeholder suggest they'd be happy in the template anyway.
This doesn't help full form/table printing, but that whole system is weak and so assumptive. Basically making template information affixed in python code in a bad way.
comment:24 by , 10 years ago
Replying to doctormo@…:
@charettes - Maybe this is something that can be fixed using a templatetag. The nature of class and placeholder suggest they'd be happy in the template anyway.
This doesn't help full form/table printing, but that whole system is weak and so assumptive. Basically making template information affixed in python code in a bad way.
I agree that handling this at the template level would make more sense. I suggest that you take a look at #15667 which track efforts to implement template based widgets. From what I remember it introduced a templatetag to add attributes to widgets.
This is related to ticket #15924, and in fact fills the requirements listed there for not being closed. As long as a patch doesn't break backwards compatibility, it should be fine. Note, however, that it's much more likely to happen if you yourself make the patch.