Opened 8 years ago

Closed 5 years ago

#6350 closed (wontfix)

CSS issue on changelist page using admin

Reported by: anonymous Owned by: xian
Component: contrib.admin Version: master
Severity: Keywords: admin, css, changelist
Cc: kent37@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

I noticed this issue using both newforms-admin and the admin app in the SVN release of Django.

The problem is if the table has too many columns or is too wide on the changelist page of the admin, it will not properly display. The paginator bar beneath the table does not stretch to the full length of the table and is cut off short. If the admin has a date_hierarchy option enabled, that bar above the changelist table does the same thing.

Additionally, if any list_filters are enabled, the filter sidebar will display above the table cutting off a view of the data. I have attached several screenshots of the issue using both Firefox and IE 6.

Thanks for your work on Django.

Attachments (6)

ff_normal.gif (5.4 KB) - added by anonymous 8 years ago.
firefox with no options enabled
ff_date_hierarchy.gif (5.6 KB) - added by anonymous 8 years ago.
firefox with date_hierarchy enabled
ff_dh_list_filter.gif (7.0 KB) - added by anonymous 8 years ago.
firefox with date_hierarchy and list_filter enabled
ie_normal.gif (5.8 KB) - added by anonymous 8 years ago.
ie with no options enabled
ie_date_hierarchy.gif (5.9 KB) - added by anonymous 8 years ago.
ie with date_hierarchy enabled
ie_dh_list_filter.gif (7.8 KB) - added by anonymous 8 years ago.
ie with date_hierarchy and list_filter enabled

Download all attachments as: .zip

Change History (12)

Changed 8 years ago by anonymous

firefox with no options enabled

Changed 8 years ago by anonymous

firefox with date_hierarchy enabled

Changed 8 years ago by anonymous

firefox with date_hierarchy and list_filter enabled

Changed 8 years ago by anonymous

ie with no options enabled

Changed 8 years ago by anonymous

ie with date_hierarchy enabled

Changed 8 years ago by anonymous

ie with date_hierarchy and list_filter enabled

comment:1 Changed 8 years ago by Kent Johnson <kent37@…>

  • Cc kent37@… added
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

This problem is also in 0.96.

comment:2 Changed 8 years ago by ubernostrum

  • Owner changed from nobody to xian

Assigning to xian since he's doing UI stuff for the admin.

comment:3 Changed 8 years ago by Simon Greenhill <dev@…>

  • Triage Stage changed from Unreviewed to Accepted

comment:4 Changed 7 years ago by jacob

  • Resolution set to wontfix
  • Status changed from new to closed

After looking at this (with a real designer - thanks, Nathan!) we've concluded that it's probably impossible to fix this in any sort of reasonable way. So for now the only solution is to use fewer rows in list_display, or to use something more designed for browsing like databrowse.

comment:5 Changed 6 years ago by rfugger

  • Resolution wontfix deleted
  • Status changed from closed to reopened

A bit of explanation as to what the exact issues are here would be helpful. Just because one designer doesn't think anything can be done doesn't mean that it's impossible.

One easy thing that could be done to start is to allow column header text to wrap so that otherwise-wide columns can be made narrow. Trying to hack this in the code doesn't work very well: You can put @@<br/>@@ in the model column name and mark it safe, but the add/change page ignores the safe marking (could open a bug on that I suppose). You can also call a method that gets the column name, and set the short_description property, but then you can't sort on that column. Simply removing the @@white-space@@ line from changelist.css:51:

{{
#changelist table thead th {

vertical-align:middle;
white-space:nowrap;

}
}}

Seems to do it.

comment:6 Changed 5 years ago by ramiro

  • Resolution set to wontfix
  • Status changed from reopened to closed

Pleasse don't reopen tickets that have been closed by a core committer. The workflow we use is that if you feel strong about a ticekt needing to be considered again, it is better to open a thread in the django-dev mailing list with a summary of the issue at hand so a greater audience of contributors and committers can participate in the discussion.

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