--
Ticket URL: <https://code.djangoproject.com/ticket/16304>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_docs: => 1
* needs_better_patch: => 0
* version: 1.3 => SVN
* needs_tests: => 1
* stage: Unreviewed => Accepted
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:1>
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:2>
Comment (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
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:3>
* owner: nobody => avenet
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:4>
* status: assigned => new
* cc: j4nu5 (added)
* needs_better_patch: 0 => 1
* owner: avenet => j4nu5
* needs_docs: 1 => 0
* has_patch: 0 => 1
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:5>
* status: new => assigned
* needs_better_patch: 1 => 0
* needs_tests: 1 => 0
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:6>
* cc: andybak (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:7>
Comment (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+
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:8>
* needs_better_patch: 0 => 1
Old description:
> 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?
New description:
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:
{{{#!python
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:
{{{#!python
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?
--
Comment:
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="...">}}}.
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:9>
* cc: lrekucki@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:10>
* cc: claire12.reynaud@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:11>
* owner: j4nu5 => anonymous
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:12>
* cc: javi.manzano.oller@… (added)
* owner: anonymous => jgasteiz
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:13>
* cc: martmatwarne (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:14>
Comment (by jgasteiz):
Github patch. [https://github.com/django/django/pull/1111/files]
Added to CharField, but applied in all input boxes and textarea.
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:15>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:16>
* needs_better_patch: 0 => 1
Comment:
Notes on pull request.
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:17>
* cc: charettes (added)
Comment:
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:
{{{
#!python
class MyModelForm(forms.ModelForm):
class Meta:
model = MyModel
widgets = {
'email': forms.TextInput({'placeholder':
'add...@domain.com'})
}
}}}
I'm slightly tempted to ''wontfix'' this ticket.
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:18>
Comment (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.
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:19>
Comment (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!"})
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:20>
Comment (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.
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:21>
* status: assigned => closed
* resolution: => wontfix
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:22>
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:23>
Comment (by charettes):
Replying to [comment:23 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/16304#comment:24>