Opened 17 years ago

Closed 14 years ago

#6350 closed (wontfix)

CSS issue on changelist page using admin

Reported by: anonymous Owned by: xian
Component: contrib.admin Version: dev
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: no UI/UX: no

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 17 years ago.
firefox with no options enabled
ff_date_hierarchy.gif (5.6 KB ) - added by anonymous 17 years ago.
firefox with date_hierarchy enabled
ff_dh_list_filter.gif (7.0 KB ) - added by anonymous 17 years ago.
firefox with date_hierarchy and list_filter enabled
ie_normal.gif (5.8 KB ) - added by anonymous 17 years ago.
ie with no options enabled
ie_date_hierarchy.gif (5.9 KB ) - added by anonymous 17 years ago.
ie with date_hierarchy enabled
ie_dh_list_filter.gif (7.8 KB ) - added by anonymous 17 years ago.
ie with date_hierarchy and list_filter enabled

Download all attachments as: .zip

Change History (12)

by anonymous, 17 years ago

Attachment: ff_normal.gif added

firefox with no options enabled

by anonymous, 17 years ago

Attachment: ff_date_hierarchy.gif added

firefox with date_hierarchy enabled

by anonymous, 17 years ago

Attachment: ff_dh_list_filter.gif added

firefox with date_hierarchy and list_filter enabled

by anonymous, 17 years ago

Attachment: ie_normal.gif added

ie with no options enabled

by anonymous, 17 years ago

Attachment: ie_date_hierarchy.gif added

ie with date_hierarchy enabled

by anonymous, 17 years ago

Attachment: ie_dh_list_filter.gif added

ie with date_hierarchy and list_filter enabled

comment:1 by Kent Johnson <kent37@…>, 17 years ago

Cc: kent37@… added

This problem is also in 0.96.

comment:2 by James Bennett, 17 years ago

Owner: changed from nobody to xian

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

comment:3 by Simon Greenhill <dev@…>, 17 years ago

Triage Stage: UnreviewedAccepted

comment:4 by Jacob, 16 years ago

Resolution: wontfix
Status: newclosed

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 by Ryan Fugger, 15 years ago

Resolution: wontfix
Status: closedreopened

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 by Ramiro Morales, 14 years ago

Resolution: wontfix
Status: reopenedclosed

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