275631 - Only the first column (not all) should have excess CSS padding-left

Status: RESOLVED FIXED

(Bugzilla :: User Interface, defect)

Description

[psellhorst]

The current setup for default bug lists makes it hard to
read the most important part, the summary, on an 800x600
display. Due to the increased padding everywhere, the
summary column is pushed far to the right and reading its
contents fully is only possible when using horizontal
scrolling.

Now this can probably be worked around by choosing custom
columns and/or specific CSS rules, but I feel that the
default appearance should be designed in a way that makes
additional modifications for this purpose unnecessary.
I am also aware that the visual table layout may depend
on parameters specific to a certain Bugzilla installation,
the longest unwrappable string and other issues beyond
Bugzilla's control. However, the bug lists really were
easier to read before the recent upgrade.

Comment 1

[psellhorst]

Attachment: Screenshot

Hard-to-read bug list (Firefox bugs)

Comment 2

[psellhorst]

Attachment: Screenshot

Comparison: old-school bug list from eclipse.org

Comment 3

[:glob ✱]

Attachment: remove extra padding

the extra padding in the buglist has been annoying me as well.

20px padding-left was added to make room for the secure icon, however it was
added to all columns instead of just the first one.

Comment 4

[Felix Miata]

Did either of you bother searching for the existing bug 274448 that this is a
duplicate of?

Comment 5

[:glob ✱]

*** Bug 274448 has been marked as a duplicate of this bug. ***

Comment 6

[Felix Miata]

Answer the question please.

Comment 7

[:glob ✱]

(In reply to comment #6)
> Answer the question please.

yes i searched.  obviously i didn't find your bug.  it happens, get over it.

Comment 8

[psellhorst]

(In reply to comment #4)
> Did either of you bother searching for the existing bug 274448 that this is a
> duplicate of?

I'm sorry I didn't see the older bug. It wasn't in the regressions list, and a
search for "padding" turned up nothing. Personally, I'm happy to see a patch
addressing this issue, no matter what bug number it's attached to.

Comment 9

[Gervase Markham [:gerv]]

Comment on attachment 169346 [details] [diff] [review]
remove extra padding

Is it really necessary for it to be !important? If so, r=gerv.

Gerv

Comment 10

[:glob ✱]

Comment on attachment 169346 [details] [diff] [review]
remove extra padding

thanks for the review gerv.

however i've just realised this looks shaft in IE (the padding looks like it's
about 100px).

Comment 11

[:glob ✱]

Attachment: remove extra padding v2

the IE issue has been fixed by bug 232328.

i swear that while developing this patch the !important was required. 
apparently it is not.

this patch is the same as the first, minus !important.

not sure if i can carry forward the r+, so rerequesting.

Comment 12

[Vlad Dascalu]

I had to do minor tweaking on the patch in order to apply it to the 2.18 branch.

Checking in skins/standard/buglist.css;
/cvsroot/mozilla/webtools/bugzilla/skins/standard/buglist.css,v  <--  buglist.css
new revision: 1.8; previous revision: 1.7
done
Checking in template/en/default/list/table.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/list/table.html.tmpl,v 
<--  table.html.tmpl
new revision: 1.23; previous revision: 1.22
done

Checking in css/buglist.css;
/cvsroot/mozilla/webtools/bugzilla/css/Attic/buglist.css,v  <--  buglist.css
new revision: 1.2.4.5; previous revision: 1.2.4.4
done
Checking in template/en/default/list/table.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/list/table.html.tmpl,v 
<--  table.html.tmpl
new revision: 1.16.2.6; previous revision: 1.16.2.5
done

Comment 13

[David E. Ross]

This has been fixed on the 2.18 branch.  Will that be propagated to 2.19?
Mozilla.org is currently using 2.19.1+, which is where this problem was first
reported.  

Comment 14

[Dave Miller [:justdave]]

(In reply to comment #13)
> This has been fixed on the 2.18 branch.  Will that be propagated to 2.19?
> Mozilla.org is currently using 2.19.1+, which is where this problem was first
> reported.  

Yes, it was checked in on both the 2.18 branch and on the trunk (which is
2.19.1+ currently).  It will very likely get pulled to mozilla.org in the next
week or so.