Code

Opened 3 years ago

Closed 11 months ago

#16304 closed New feature (wontfix)

Add HTML5 'placeholder' attribute support to form fields.

Reported by: rich@… Owned by: jgasteiz
Component: Forms Version: master
Severity: Normal Keywords: forms, placeholder, html5
Cc: charettes, j4nu5, andybak, 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 lrekucki)

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 avenet 3 years ago.
Patch for adding placeholder attribute on CharField class
16304.patch (3.9 KB) - added by j4nu5 2 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 j4nu5 2 years ago.
Adds placeholder attribute functionality to forms. Has docs. Has tests.

Download all attachments as: .zip

Change History (25)

comment:1 Changed 3 years ago by melinath

  • Needs documentation set
  • Needs tests set
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted
  • Version changed from 1.3 to SVN

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 Changed 3 years ago by melinath

  • Summary changed from Forms Need HTML5 'placeholder' attribute to Add HTML5 'placeholder' attribute support to form fields.

comment:3 Changed 3 years ago by d0ugal

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 Changed 3 years ago by avenet

  • Owner changed from nobody to avenet
  • Status changed from new to assigned

Changed 3 years ago by avenet

Patch for adding placeholder attribute on CharField class

Changed 2 years ago by j4nu5

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

comment:5 Changed 2 years ago by j4nu5

  • Cc j4nu5 added
  • Has patch set
  • Needs documentation unset
  • Owner changed from avenet to j4nu5
  • Patch needs improvement set
  • Status changed from assigned to 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.

Changed 2 years ago by j4nu5

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

comment:6 Changed 2 years ago by j4nu5

  • Needs tests unset
  • Patch needs improvement unset
  • Status changed from new to 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 Changed 20 months ago by andybak

  • Cc andybak added

comment:8 Changed 19 months ago by tonnzor

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 Changed 18 months ago by lrekucki

  • 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. Also, placeholder is also legal on <textarea> not only variations of <input type="...">.

Version 0, edited 18 months ago by lrekucki (next)

comment:10 Changed 18 months ago by lrekucki

  • Cc lrekucki@… added

comment:11 Changed 11 months ago by Claire Reynaud <claire12.reynaud@…>

  • Cc claire12.reynaud@… added

comment:12 Changed 11 months ago by Javi Manzano <javi.manzano.oller@…>

  • Owner changed from j4nu5 to anonymous

comment:13 Changed 11 months ago by jgasteiz

  • Cc javi.manzano.oller@… added
  • Owner changed from anonymous to jgasteiz

comment:14 Changed 11 months ago by martmatwarne

  • Cc martmatwarne added

comment:15 Changed 11 months ago by jgasteiz

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

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

comment:16 Changed 11 months ago by jgasteiz

  • Patch needs improvement unset

comment:17 Changed 11 months ago by lrekucki

  • Patch needs improvement set

Notes on pull request.

comment:18 Changed 11 months ago by charettes

  • Cc charettes 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 Changed 11 months ago by jgasteiz

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 Changed 11 months ago by lrekucki

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 Changed 11 months ago by jgasteiz

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 Changed 11 months ago by charettes

  • Resolution set to wontfix
  • Status changed from assigned to 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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.