142104 - (grey_enhancements) enhancements in buglists should be grey

Status: RESOLVED FIXED

(Bugzilla :: Query/Bug List, defect)

Description

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Bugs marked as enhancements are currently shown in italic in buglists. This 
looks very reversed since enhancements should get *less* attention, not more. I 
suggest we use some gray color (|color: light gray;| is good IMHO) instead and 
remove the italic font-style.

I know there are plans to design a better styling system for the buglist, but 
this is just a request to change the default from italic to gray, both until we 
get the new styling system, and as defaults in the new styling system.

Comment 1

[Håkan Waara]

I totally support this! Just as we give blockers the screaming red color, we
need to give RFEs less attention.

Comment 2

[Håkan Waara]

It doesn't have to be CSS color "gray", it can be darker, as long as it gives
you the feeling that "disabled" widgets do in operating systems.

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

color: #666

looks very good to me, it's dark enough to be easy to read but still stands out 
as "grayed"

Comment 4

[Jouni Heikniemi]

Attachment: Patch

#666 is way too black at least on my monitor, can't easily see it apart from
normal black font. That's why I propose #888. Patch for that attached.

Comment 5

[Christian Reis]

Comment on attachment 82256 [details] [diff] [review]
Patch

I'm fine with this change, since italics generate lots of complaints from
mozilla hackers.

Comment 6

[Christian Reis]

Anybody else want to chip in a 2r= ?

Comment 7

[Andreas Franke (gone)]

Comment on attachment 82256 [details] [diff] [review]
Patch

A side-effect of the proposed change is that secure enhancements won't be
styled different from other secure bugs any more, since secure bugs have
.bz_secure { color: black; background-color: lightgrey; }
on them. Commenting out the /*color: black;*/ there seems to help, though; with
this change, even secure bugs are still readable for me.

I'm not sure if styling enhancements by color is any better than using italics,
but I'm not opposed to it either.

Comment 8

[Håkan Waara]

Try putting in an !important there, if you want secure bugs' text-color to
always be black.

Comment 9

[Jouni Heikniemi]

Before I propose another color combination, I would like to understand what is
relevant for the secure bugs.

Even in the current state of the CSS, secure criticals won't be styled
differently from other secure bugs, since the critical severity style also uses
only font color. Now the patch was marked needs-work because secure enhancements
could no longer be separated from other secure bugs. Does this apply also to
secure criticals? Should they get fixed as well? Afranke, your comments please.


I can't find #888 (nor red) on lightgray readable. I can see it now, but if I
look at it through an older 17" tube, that's kind of hard to read. So I don't
believe in fixing this by only removing color: black from bz_secure class style.

>I'm not sure if styling enhancements by color is any better than using 
>italics, but I'm not opposed to it either.

The problem is that italics indicates emphasis (although on some display
settings it may actually decrease the font weight). I don't think we intend to
particularly emphasize the enh severity bugs, but rather fade them out. This is
why italics is incorrect imho.

Unfortunately there are only few ways of typographically un-emphasizing things.
Decreasing font size is "the right thing", but the result is stylistically
unacceptable within large tables. If no visual symbols can be used, then color
is pretty much the only way. 

Comment 10

[Andreas Franke (gone)]

Comment on attachment 82256 [details] [diff] [review]
Patch

Ok, ok, ok. :-)
I just wanted someone else to look at it. If the side-effect is intentional,
then it's fine with me. I hadn't realized that for secure bugs, the styling of
critical bugs is lost, too. Removing the "needs-work" flag.

So if you (hwaara, jouni) are fine with this patch, please mark it
second-review. (You are looking at buglists more often than me.)

Comment 11

[Andreas Franke (gone)]

Sorry, I forgot that the patch is from jouni. So hwaara, you as a moz developer,
if you find this patch acceptable, it would be nice if you could mark it
second-review.

Comment 12

[Christopher Aillon (sabbatical, not receiving bugmail)]

Can we wait on physically coloring/styling this and wait until we have user
preferences for this sort of stuff?  Just put class names there and document how
to set user style sheets.  NS6/Moz/IE5 let you do that.  This thing should not
be statically colored -- it should be set by the user. Then in the 2.18
timeframe when we get the user prefs table working, we can do this as a pref.

Comment 13

[Jouni Heikniemi]

Should we abandon all other styling as well? I have found the new coloring
helpful, even though I haven't configured the colors myself. Doing user
stylesheets is a ridiculously painful job if you have several browsers on
several computers, and I wouldn't expect a large mass of users to bother with that.

I'm not against promoting user stylesheets, but this is about giving sensible
defaults. I think the current coloring and this patch are acceptable as such.

Comment 14

[Håkan Waara]

Caillon, I don't really see why this should wait, given that we already style
the lists; and the reason for this bug is that we actually give RFEs *better*
visibility than other higher-priority bugs.  I say either we abandon styles
altogether, or we fix the too high visibility of RFEs.

I'd be happy (upon request) to mark the patch second-review, but I'm not really
a bugzilla developer. If you really want it though, second-review=hwaara, I
guess. :-)

Comment 15

[Christopher Aillon (sabbatical, not receiving bugmail)]

> I don't really see why this should wait, given that we already style
the lists; and the reason for this bug is that we actually give RFEs *better*
visibility than other higher-priority bugs.  I say either we abandon styles
altogether, or we fix the too high visibility of RFEs.

Because, the styling is only available on *this* copy of Bugzilla, eg
bugzilla.mozilla.org.  There has never been any official bugzilla release which
has the existing red styling you see day in and day out.  Bugzilla 2.16 will
have templates.  I suggest turning this RFE into an RFE pertaining specifically
to bugzilla.mozilla.org and not Bugzilla as a whole.  I agree with you that we
should abandon styles altogether in the release of Bugzilla 2.16 and let each
installation's administrator style as they see fit.

In addition, I find the changing of foreground colors distracting.  Wouldn't a
better RFE seek coloring the background color different shades of one color? 
See how sourceforge does this.  Critical bugs have a solid red background, while
less important bugs' background colors fade out.  This is much easier for a
human to notice at a glance rather than having him figure out which color means
what....

Comment 16

[Jouni Heikniemi]

>Because, the styling is only available on *this* copy of Bugzilla, eg
>bugzilla.mozilla.org.  There has never been any official bugzilla release which
>has the existing red styling you see day in and day out.

True, but how is this relevant? I mean, there are quite a lot of features which
are only available in cvs versions. 

If your point is that default installation of bugzilla shouldn't contain
styling, I disagree strongly. Besides, the current layout is styled too, though
maybe less prominently. The closest styling I can see right now is the enlarged
font size of the "View Bug Activity" link. And that's not the only part using
big, small and similar markup. Where do you draw the line? I mean, it isn't
relevant whether it's CSS we're using or not, huh? 

>I agree with you that we should abandon styles altogether in the release of 
>Bugzilla 2.16 and let each installation's administrator style as they see fit.

I cannot see how default styling conflicts with each administrator's freedom to
configure their installation. On the other hand, I know how much of a job it is
to do some customizations. I cannot see why the BZ default installation
shouldn't offer reasonable defaults, just other pieces of software do. 

Let's face it: the majority of Bugzilla installations won't be customized
because of lazy/busy/whatever admins. If a large number of people find the
coloring useful, then providing it with the default installation is an overall
improvement for Bugzilla. I think the b.m.o feedback (what little I have heard
of it) shows that the changes have been for the better.

>In addition, I find the changing of foreground colors distracting.  Wouldn't a
>better RFE seek coloring the background color different shades of one color? 

That is another matter entirely. What is good for one's eye is bad for
another's. I think this is a reason for discussion, not for abandoning features.
As already noted on this bug, it is possible to user-customize the styling.
Altering the foreground color isn't AFAIK generally considered harmful on the
web, though.

Personally I dislike SourceForge bug tracker's coloring, mainly because even the
critical bugs can have a relatively poor fg/bg contrast. I'd say that playing
with background colors is usability-wise riskier than changing the text color,
but the practical impact depends on several issues. Besides, I know many people
who surf with background colors entirely disabled because of the contrast problems. 

Background colors could be used, but they would probably have a heavy impact on
Bugzilla's otherwise whitish UI (this part is certainly different from
SourceForge). I think it's a good idea to support SourceForge-style coloring,
but  since many people find the Bugzilla style better, these two should be
options. The admin can choose one of them, his own style or no styling at all.

I think the current b.m.o style is the best choice for the default. Although
b.m.o != Bugzilla, I still think many people are already used to this. If we're
ready the change things like query screen layout, it shouldn't be that hard to
change the default colors either.

Comment 17

[Matthew T (active 1999-2002)]

Comment on attachment 82256 [details] [diff] [review]
Patch

needs-work. When you specify `color' in CSS, you should always specify
`background-color' as well (and vice versa). If you are sure that the inherited
background color is never going to be similar enough to the specified color to
cause unreadability, then you should use `background-color: inherit;' to
indicate that.

Comment 18

[Jouni Heikniemi]

Mpt: 

We _are_ defining the background color, although we are not explicitly setting
the css property called background-color. The background color is set in the
header template through bodyhtml param - the body element's attribute
collection. The default bodyhtml is defined in defparams.pl as containing
bgcolor="#ffffff". Using html markup like this is not good, but outside the
scope of this bug.

Any background-color value other than inherit would be foolish, since that would
split the bg color definition into several places. Given the current situation,
I don't think it's necessary to bloat the CSS files by adding inherits
everywhere, since that's the default value anyway. If we decide to do so, we
have to patch the whole css file and all the "<font color=...>" thingies
scattered in the templates. We must rely on background color inheritance IMO. 

If you still maintain that the background-color: inherits should be explicitly
specified, please state so and I'll create another patch. Feel free to assign
this to me while you're at it.

Comment 19

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

actually, the default-value for background-color is "transparent". So setting 
|background-color: inherits| will just inherit the transparent-value and have 
no effect, unless the same is done all the way up to the element with the 
background-color (in this case the <body>.

But doing that would IMHO look very ugly in the css and would be a pain for 
browsers to render since the same background would be painted for every element 
instead of just once for the entire page.

Comment 20

[Jouni Heikniemi]

Oops, of course the default is transparent. Thanks for the correction.

So much for using inherit. I don't think tagging the default transparent value
to every element is necessary either. The body level background definition
should suffice - it certainly does that for browsers.

Comment 21

[Jouni Heikniemi]

To summarize what has happened so far:

1. It has been proposed that enh severity bugs should be shown in gray.
   There is a patch for this approach.
2. There has been discussion over whether foreground colors should be used
   for styling at all.
3. There has been discussion about how the background colors should be 
   specified in the CSS files.

The patch for issue 1 is now needs-work because of issue 3. It is to be noted
that the current situation has foreground color styling and no CSS background
definitions (but see comment 18). 


Now, my opinions on the issue:

This bug has been summarized to cover only issue 1, and I don't think this
should be morphed. Issues 2-3 are valid points for discussion and patching when
a decision has been made, but they should be separate bugs. However, I don't
think they should prevent evaluating the merits of changing italics to gray text
color itself, as this patch doesn't affect the current state of either issue 2 or 3.

I think the current needs-work on the patch is based on a problem not covered by
this bug. I would gladly make a new patch if all the other color definitions in
the CSS would hold a "background-color: transparent", but since none do, it
doesn't IMO make sense to break style here. 

So, what I really would want (in this bug) is comments on how the enh severity
bugs should be styled. If the resolution is wontfix, I'm fine with it, but I
wouldn't want this change to be buried under a heap of other ambitions about
enhancing Bugzilla styling. If someone wants to do issues 2 and 3, new bugs are
in order. 

Reviewers, please comment on how do you wish to proceed in this issue.

I'm taking the bug and ccing mpt (who marked the needs-work).

Comment 22

[Christian Reis]

mpt's nit refers to problems that may occur when a user has customized his
background colour; the light gray may easily become illegible. I don't think
this is a common problem, but it's reasonable.

IMO just hardcode it gray on white, which is what most places will use, and site
administrators can customize the css file as desired. 

(I think we've not had accessibility reports of problems stemming from
background contrast problems so far, so I would be fine with the first patch,
but the W3C recommends, we perform.)

Comment 23

[Jouni Heikniemi]

Kiko: please see comment 18 (and sicking's correction to technical details,
comment 19).

The background color has already been specified and a conforming browser should
not encounter the problems you mentioned. I agree it is ugly to have some color
definitions set in HTML and some in CSS, but that problem is out of the scope of
this bug. So I still think it's not good to define anything background-related
in buglist.css as long as all background properties are not there.

Comment 24

[Jouni Heikniemi]

It should also be noted that bug 147272 fixes the background coloring issue
explicitly, rather than counting on the defaults or a proper custom value being
used. 

Comment 25

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

IMHO it would be ok to set |background: white| on .bz_enhancement. If someone 
configures their bugzilla to use a non-white backcolor there is a bigger risk 
of gray text getting harder to read then red. So the problem might be specific 
to enhancements (as opposed to everywhere where we set the text-color). 
Explicitly setting a white background will at least make sure that the text is 
readable.

Comment 26

[Jouni Heikniemi]

Attachment: Patch v2

I still disagree on some of the points here, but Sicking's suggestion of adding
the explicit white setting here is acceptable. Particularly I disagree about
gray being more harmful than red for example, but this is debatable and maybe
not worth it in this context. Admins willing to customize their configurations
can make one more change as well, but this shouldn't become a habit.

So, my next proposal: add color: #888 and background-color: white. How's this?

Comment 27

[Christian Reis]

Comment on attachment 85945 [details] [diff] [review]
Patch v2

Thanks. r=kiko

Can one other senior approve of this change, please?

Comment 28

[Christian Reis]

grey -> gray 

english, *sigh*

Comment 29

[Gervase Markham [:gerv]]

gray -> grey.

If you are going to use English, use _English_ :-) I have no real view either
way on this question; I have no difficulty intepreting the italics.

Gerv

Comment 30

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Gerv: the idea is that italics are mostly used to put emphasis on something
(most UAa render <em> in italics), which probably isn't what we wanna do for
enhancements.

Instead we should put _less_ emphasis on enhancements, which is suggested to do
by rendering them gray.

Comment 31

[Gervase Markham [:gerv]]

I understand the idea. :-) I personally don't read italics as emphasis. But
maybe that's just me. My point is that I don't mind.

Gerv

Comment 32

[timeless]

personally i don't think of italics as emphasis the same way other people do, 
partly because italics tends to look rather thin.

imo <em> should render with slant and +weight

but.. whatever :)

Comment 33

[Bradley Baetz (:bbaetz)]

I prefer italics too - the letters look slightly thinner to me.

Maybe we should ask for opinions on teh newsgroups?

Comment 34

[Håkan Waara]

It's very basic typography that italics emphasize a given word or meaning, IMHO
it has nothing to do with preference. Graying out RFEs will make them look less
significant, in comparison with the other bugs in buglists. Now, can we checkin
the patch already?

Comment 35

[Jouni Heikniemi]

Hmm... A single-line change to a css file, and this has been open for 8 months?
At this point, I really don't care what Bugzilla's default is going to be, so
it's not worth fighting over. 

Since the patch has a review (while certainly not a unanimously supported one),
I'll just ask for approval and let Dave/Myk pick between gray and italicized
enhancements. :-)

Comment 36

[Joel Peshkin]

Um.....  doesn't this conflict with the bz_secure style?

Comment 37

[Jouni Heikniemi]

Joel, see comment 7, 9 and 10.

Comment 38

[Dave Miller [:justdave]]

ehhh, why the hell not... ? :)

It is only a default after all, and site administrators are free to override it
in the template if they don't like it.

Although I personally view italics as a de-emphasis in this context (because the
slanted font used to render it is thinner), it is true that under normal
circumstances, italics are used to emphasize something (like "I am <i>really</i>
sick of this discussion!" :)  So we might as well make the default not use italics.

Comment 39

[Jouni Heikniemi]

Great. :-)

Checking in buglist.css;
/cvsroot/mozilla/webtools/bugzilla/css/buglist.css,v  <--  buglist.css
new revision: 1.2; previous revision: 1.1
done