Opened 13 years ago
Last modified 2 years ago
#16149 new New feature
Allow disabling choices in a <select>
Reported by: | Jody McIntyre | Owned by: | |
---|---|---|---|
Component: | Forms | Version: | 1.3 |
Severity: | Normal | Keywords: | |
Cc: | Sergiy Kuzmenko, kitsunde@…, bmispelon@…, Fabio Caritas Barrionuevo da Luz | Triage Stage: | Accepted |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
We need to be able to disable choices in a <select>, which is done by setting the disabled attribute on the <option> tag, for example:
<option value="bananas" disabled="disabled">Bananas</option>
Currently we're doing this by subclassing the Select widget:
http://djangosnippets.org/snippets/2453/
It would be nice if the built in Select widget supported this. One way would be to replace the existing render_option method with what I've written, and I can prepare a patch if desired, but this approach changes the format of the "choices" data structure to something that won't be understood by other widgets. Perhaps these widgets should be improved too, but I don't want to do this unless the patch has a chance of being accepted.
Attachments (1)
Change History (10)
comment:1 by , 13 years ago
Component: | Uncategorized → Forms |
---|---|
Triage Stage: | Unreviewed → Design decision needed |
Type: | Uncategorized → New feature |
comment:2 by , 13 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
follow-up: 4 comment:3 by , 13 years ago
Cc: | added |
---|
This should be generic enough to accept any HTML attributes, such as class, style, id etc. Creating specialized patch for a single attribute doesn't sound very appealing to me.
comment:4 by , 13 years ago
UI/UX: | unset |
---|
Replying to shelldweller:
This should be generic enough to accept any HTML attributes, such as class, style, id etc. Creating specialized patch for a single attribute doesn't sound very appealing to me.
Thanks for the input. I don't understand the use case for passing these kinds of attributes to an <option> though. Please contribute to the discussion on django-developers if you can provide one: https://groups.google.com/d/topic/django-developers/2E3YuAUotFs/discussion
comment:5 by , 12 years ago
Cc: | added |
---|
comment:6 by , 12 years ago
Triage Stage: | Design decision needed → Accepted |
---|
The discussion raised several concerns which must be addressed, but no one's against the idea.
comment:7 by , 12 years ago
Cc: | added |
---|
Just for the record, I've just closed #5116 as a duplicate of this issue.
Its approach was to disable some choices based on their position in the choices
list.
I think the approach in this ticket is a bit better, though I would like it to be more general than simply dealing with the disabled
attribute.
I think it's a valid use-case to want to add a class
attriute to an <option>
too.
There's also an issue here that I think should be adressed:
Currently, it's perfectly valid to have two <option>
that have the same value. With the current patch however, it's not possible to selectively disable only one of them (since a set of all the values is used under the hood).
comment:8 by , 3 years ago
Owner: | removed |
---|---|
Status: | assigned → new |
comment:9 by , 2 years ago
Cc: | added |
---|
Two remarks about your proposal:
Both of these points (and maybe others) require a discussion on the django-dev mailing list.