Add HTML5 'placeholder' attribute support to form fields.

[rich@…]

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?

[Stephen Burrows]

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.

[Dougal Matthews]

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

[Andy Venet]

Patch for adding placeholder attribute on CharField class

[Kushagra Sinha]

Adds placeholder attribute functionality to Model forms and normal forms. Has docs. Does not have tests

[Kushagra Sinha]

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.

[Kushagra Sinha]

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

[Kushagra Sinha]

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.

[Artem Skoretskiy]

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+

[Łukasz Rekucki]

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="...">.

[Javi Manzano]

Github patch. ​https://github.com/django/django/pull/1111/files

Added to CharField, but applied in all input boxes and textarea.

[Łukasz Rekucki]

Notes on pull request.

[Simon Charette]

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.

[Javi Manzano]

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.

[Łukasz Rekucki]

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!"})

[Javi Manzano]

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.

[Simon Charette]

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.

[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.

[Simon Charette]

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.