Opened 13 years ago

Closed 12 years ago

Last modified 10 years ago

#16304 closed New feature (wontfix)

Add HTML5 'placeholder' attribute support to form fields.

Reported by: rich@… 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 Łukasz Rekucki)

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)

placeholder.patch (1.3 KB ) - added by Andy Venet 13 years ago.
Patch for adding placeholder attribute on CharField class
16304.patch (3.9 KB ) - added by Kushagra Sinha 13 years ago.
Adds placeholder attribute functionality to Model forms and normal forms. Has docs. Does not have tests
16304_v2.patch (3.2 KB ) - added by Kushagra Sinha 13 years ago.
Adds placeholder attribute functionality to forms. Has docs. Has tests.

Download all attachments as: .zip

Change History (27)

comment:1 by Stephen Burrows, 13 years ago

Needs documentation: set
Needs tests: set
Triage Stage: UnreviewedAccepted
Version: 1.3SVN

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.

comment:2 by Stephen Burrows, 13 years ago

Summary: Forms Need HTML5 'placeholder' attributeAdd HTML5 'placeholder' attribute support to form fields.

comment:3 by Dougal Matthews, 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 Andy Venet, 13 years ago

Owner: changed from nobody to Andy Venet
Status: newassigned

by Andy Venet, 13 years ago

Attachment: placeholder.patch added

Patch for adding placeholder attribute on CharField class

by Kushagra Sinha, 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 Kushagra Sinha, 13 years ago

Cc: Kushagra Sinha added
Has patch: set
Needs documentation: unset
Owner: changed from Andy Venet to Kushagra Sinha
Patch needs improvement: set
Status: assignednew

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 Kushagra Sinha, 13 years ago

Attachment: 16304_v2.patch added

Adds placeholder attribute functionality to forms. Has docs. Has tests.

comment:6 by Kushagra Sinha, 13 years ago

Needs tests: unset
Patch needs improvement: unset
Status: newassigned

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 Andy Baker, 12 years ago

Cc: Andy Baker added

comment:8 by Artem Skoretskiy, 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 Łukasz Rekucki, 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="...">.

Last edited 12 years ago by Łukasz Rekucki (previous) (diff)

comment:10 by Łukasz Rekucki, 12 years ago

Cc: lrekucki@… added

comment:11 by Claire Reynaud <claire12.reynaud@…>, 12 years ago

Cc: claire12.reynaud@… added

comment:12 by Javi Manzano <javi.manzano.oller@…>, 12 years ago

Owner: changed from Kushagra Sinha to anonymous

comment:13 by Javi Manzano, 12 years ago

Cc: javi.manzano.oller@… added
Owner: changed from anonymous to Javi Manzano

comment:14 by martmatwarne, 12 years ago

Cc: martmatwarne added

comment:15 by Javi Manzano, 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 Javi Manzano, 12 years ago

Patch needs improvement: unset

comment:17 by Łukasz Rekucki, 12 years ago

Patch needs improvement: set

Notes on pull request.

comment:18 by Simon Charette, 12 years ago

Cc: Simon Charette 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 Javi Manzano, 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 Łukasz Rekucki, 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 Javi Manzano, 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 Simon Charette, 12 years ago

Resolution: wontfix
Status: assignedclosed

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.

comment:23 by doctormo@…, 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.

in reply to:  23 comment:24 by Simon Charette, 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.

Note: See TracTickets for help on using tickets.
Back to Top