Opened 6 months ago
Closed 6 months ago
#36317 closed Bug (invalid)
ModelChoiceField cannot be hidden by default
Reported by: | Josh Piasecki | Owned by: | |
---|---|---|---|
Component: | Forms | Version: | 5.2 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
hello all, I have run into something that feels like a bug to me, but i could be wrong there may be a reason for this behavior.
I have added a custom action form to my Admin page.
my goal is to default these fields to hidden and only show them when the associated action is selected.
I have accomplished this with JS, however there is a delay before it is loaded and there is a small layout shift.
the form contains two fields, the relevant code is below.
choice = ModelChoiceField( ... widget=Select( attrs={ "style": "display: none;" } ), ) date = DateField( ... widget=DateInput( attrs={ "style": "display: none;", } ), )
the DateInput is appropriately hidden when the template is rendered and requires no JS to hide the input initially.
however, because the way dropdowns are rendered in html. the ModelChoiceField is not correctly hidden.
the rendered html basically looks like this:
<label> <select style="display: none;" /> <span /> </label>
the problem is that the <select>
element is hidden by default and the <span>
is what the user actually interacts with.
so the expected behavior is that when display: none;
is set on the widget, the widget is hidden.
it would be nice if Django was smart enough to set display: none;
on all the associated elements to the widget for this particular case.
Hello Josh Piasecki, thank you for your ticket!
I believe that the behavior you describe derives from the structure of the rendered HTML and how CSS
display: none;
affects different elements. While it may seem like a bug, it aligns with standard HTML and CSS behavior. Given this, and given that the Django ticket tracker is best suited for confirmed or reproducible issues within Django itself, I'm afraid I have to close this asinvalid
.This particular scenario appears to be more of a usage question or a request for implementation advice. Therefore, it would be more appropriate to discuss this on the Django Forum, where community members can provide guidance and potential solutions. If, through community discussion, this is identified as a potential improvement for Django, we can revisit and consider reopening the ticket. Thank you for your understanding.