Opened 8 years ago
Closed 8 years ago
#29248 closed Bug (fixed)
Model field names can conflict with admin's field-box CSS class
| Reported by: | Phil Gyford | Owned by: | Faheel Ahmad |
|---|---|---|---|
| Component: | contrib.admin | Version: | 2.0 |
| Severity: | Normal | Keywords: | |
| Cc: | elky | Triage Stage: | Ready for checkin |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | yes | UI/UX: | no |
Description
In Admin edit screens, fields are given a CSS class with their field name. e.g. A model field called title will have its input field, label, etc, surrounded by a div like: <div class="form-row field-title">.
However there is a field-box class used in admin's forms.css stylesheet:
fieldset .field-box {
float: left;
margin-right: 20px;
}
So, if you have a model with a field called box, then when it's displayed on an Admin edit screen it is floated left and the next field appears to its right:
I think that field-box is the only such potential conflict in forms.css. I guess it should be renamed to something that does not start with field-?
Change History (6)
comment:1 by , 8 years ago
| Cc: | added |
|---|---|
| Summary: | Model field names can conflict with field-box CSS class in Admin → Model field names can conflict with admin's field-box CSS class |
| Triage Stage: | Unreviewed → Accepted |
comment:2 by , 8 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
It does seem like field-box is the only potentially conflicting class in forms.css as no other class starts with field-. My suggestion is to rename it to either fieldbox, fieldBox or field__box (the last one being based on the BEM methodology).
comment:3 by , 8 years ago
Since classes in forms.css are in camel case, fieldBox seems to be the appropriate choice to me. If anyone has any suggestion regarding this do let me know. I'll have a PR ready in a few days.
comment:5 by , 8 years ago
| Triage Stage: | Accepted → Ready for checkin |
|---|

A note in the "backwards incompatible changes" section of the release notes may be useful as that class has been there since Django 1.0 (7a9b55ddc4d49775a696d1d34629ebbad2499fa3).