Opened 5 years ago

Last modified 3 years ago

#16149 assigned New feature

Allow disabling choices in a <select>

Reported by: scjody Owned by: scjody
Component: Forms Version: 1.3
Severity: Normal Keywords:
Cc: shelldweller, kitsunde@…, bmispelon@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


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:

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)

select_with_disabled.diff (1.7 KB) - added by scjody 5 years ago.
WIP patch

Download all attachments as: .zip

Change History (8)

comment:1 Changed 5 years ago by aaugustin

  • Component changed from Uncategorized to Forms
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed
  • Type changed from Uncategorized to New feature

Two remarks about your proposal:

  • The API adds some boilerplate; maybe there a good reason, but it's not immediately obvious.
  • You must address carefully the backwards compatibility issue.

Both of these points (and maybe others) require a discussion on the django-dev mailing list.

comment:2 Changed 5 years ago by scjody

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

Changed 5 years ago by scjody

WIP patch

comment:3 follow-up: Changed 5 years ago by shelldweller

  • Cc shelldweller 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 in reply to: ↑ 3 Changed 5 years ago by scjody

  • 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:

comment:5 Changed 4 years ago by kitsunde

  • Cc kitsunde@… added

comment:6 Changed 3 years ago by aaugustin

  • Triage Stage changed from Design decision needed to Accepted

The discussion raised several concerns which must be addressed, but no one's against the idea.

comment:7 Changed 3 years ago by bmispelon

  • Cc bmispelon@… 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).

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