Open Bug 90315 Opened 20 years ago Updated 8 years ago

Color message by quote depth/level

Categories

(SeaMonkey :: MailNews: Message Display, enhancement)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: bugzilla2009, Unassigned)

References

Details

(Whiteboard: [please dupe TB bugs to 851022])

Attachments

(3 files)

Screenshot showing how (good) the result could look
9.47 KB, image/png
Details
Three screenshots showing that HTML e-mail is colored too.
64.70 KB, image/jpeg
Details
Screenshot showing that user-colored words are not affected (that's good)
26.53 KB, image/jpeg
Details 
I just watched and read a tread in netscape.public.mozilla.mail-news named :
"How to remove blue line from quoted text?"

It dicusses whether or not the lines before quoted text is a good thing .. some
like them , some prefer a text only view.

I have a different and IMO better suggestion on how to make quoted text more
visible and easy to spot.

Use colorcoding. A different color for each depth ( > ) of the discussion much
like Noworyta Newsreader does it ( see URL )
This could be used both with or without the blue bar way of marking.

It could even do "smart" coloring, determining which poster wrote a particular
bit of the message and assign him/her a color and REMEMBER that color , so if he
writes in the thread again he will be shown with the same color.
This is however more difficult to implement that just cycling the color based on
indention.

The signature should be colored a different color too IMO (but that may be
different enough from this RFE to warrent its own RFE bug number)
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
It's a duplicate.
Whiteboard: DUPME
Oh darn !

Of which bug ?

Couldn't find a duplicate bug (how surprising). Please disregard to my last comment.
Whiteboard: DUPME
Just found this bug. Coloring quotes by depth is already available in Mozilla. A
couple of days ago Ben Bucksch kindly explained how this can be accomplished.
See <3BE1623E.7000305@beonex.com>
Or http://www.hmetzger.de/tips6/coloredquotes.html (in German)

- Holger
Annotation re colored signature:
This has always been available as well. Sometimes it's broken though. :-)
You can change the sig color as well by adding an entry to userContent.css:

.moz-txt-sig, .moz-signature { 
 color: red !important; 
 } 
 .moz-txt-sig > a, .moz-signature > a { 
 color: CC0033 !important; 
 }

Holger
*** Bug 112835 has been marked as a duplicate of this bug. ***
*** Bug 116270 has been marked as a duplicate of this bug. ***
Seth: Any objections, if I take this?

If we don't allow the user to set the colors, this should be fairly easy to
implement (because we basically just have to give it a UI). Otherwise, we could
lend implementation ideas from the labels feature, but I'm not sure, if I would
implement that (too much work).
I think the user should be able to change the colors for the different quoting 
depths.
But if the colorassignment was smart enough to assign different colors for each 
poster (and remember them) then I could see it would quickly get complex.
Maybe a setting to determine your OWN color could be used.

I would be grateful just to see any implementation right now .. even an easy 
one. Then a abitious implementation could be done at a later time.

.. I just got an idea ! - There is no need remember a specific color for each 
poster.
We could just do a MD5 or similar algoritm that produces a fairly unique 
result , on the posters emailaddress or name or both and use the result to 
determine the color.
That way the same poster would always get the same color and we didn't have to 
keep track of what color he/she was assigned the last time we choose a color 
for him/her.

As long as we make sure the resulting color does not blend in with the 
background in the messagewindow , then I think it would work great.

Then the only colors the user should be able to choose (or if you want , we 
choose it for him) is the color of the signature and the color of him/herself

btw I have no objections to Ben taking this RFE.

This useful feature is already available by editing userContent.css and adding
the following lines:

**********************************************************++

blockquote[type=cite] {
color: navy ! important;
}
blockquote[type=cite] blockquote {
color: maroon ! important;
}
blockquote[type=cite] blockquote blockquote {
color: green ! important;
}
blockquote[type=cite] blockquote blockquote blockquote {
color: purple ! important;
}
blockquote[type=cite] blockquote blockquote blockquote blockquote {
color: teal ! important;
}

**********************************************************++

All we really need yet is some *UI* to let the user discover and set the color
values. The UI could be copied/modified from existing programs. I think OE has a
decent UI for this (with visual cues as to what one is adjusting).

Also useful would be some *default colors* some new users can benefit from this. :)
Keywords: polish
I'm not sure we can do UI for this very easily, but I think we still want it.

http://www.hmetzger.de/net7comp.html has a fix for it too:

blockquote[type=cite] { 
color: navy ! important; 
} 
blockquote[type=cite] blockquote { 
color: maroon ! important; 
} 
blockquote[type=cite] blockquote blockquote { 
color: green ! important; 
} 
blockquote[type=cite] blockquote blockquote blockquote { 
color: purple ! important; 
} 
blockquote[type=cite] blockquote blockquote blockquote blockquote { 
color: teal ! important; 
} 
span[_moz_quote=true] {
color: green !important;
} 

I want to move that into the core product, let me ask the author first for his 
approval.

before I do that, I'll check with some layout / css experts that this way of 
doing it is the most efficient
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2beta
>I think OE has a decent UI for this 
> (with visual cues as to what one is adjusting).

peter, can you screen shot OE's UI for this?


> I want to move that into the core product, let me ask the author first for his 
> approval.

As Holger said in comment 5 *, I am the original author of these rules (and of
the code to which they hook up), and I grant permission to use it unter the
MPL/LGPL dual license. However, I prefer the following rules:

blockquote[type=cite] {
  border-color: gray ! important;
  color: red ! important;
}
blockquote[type=cite] blockquote {
  border-color: red ! important;
  color: green ! important;
}
blockquote[type=cite] blockquote blockquote {
  border-color: green ! important;
  color: blue ! important;
}
blockquote[type=cite] blockquote blockquote a {
  color: fuchsia;
}
blockquote[type=cite] blockquote blockquote blockquote {
  border-color: blue ! important;
  color: gray ! important;
}
blockquote[type=cite] blockquote blockquote blockquote blockquote {
  border-color: gray ! important;
}
blockquote[type=cite] pre, blockquote[type=cite] div {
  color: inherit ! important;
}

This colors the quote bars matching to who added the corresponding ">"s.

The place to add the rules could be messageBody.css. You'd probably have to
remove the !important. However, this would collide logically and on the code
level with our existing quote color pref.

We discussed a UI for this. It was on np.m.mail-news, IIRC, but I don't know a
reference. Maybe some other people here can remember/search for it.

The UI is tricky for implementation, because we don't have infrastructure to
write css from prefs (if we did, this would probably simplify the libmime
txt->html code quite a bit).
> this would collide logically and on the code
> level with our existing quote color pref.

Hmm, I forgot about that pref.

> The UI is tricky for implementation, because we don't have infrastructure to
> write css from prefs (if we did, this would probably simplify the libmime
> txt->html code quite a bit).

yes, we've had this problem before.  I've looked into creating and apply style 
sheets from C++, but we found another way. 

see how were' doing labels:

http://lxr.mozilla.org/mozilla/source/themes/modern/messenger/threadPaneLabels.c
ss (and nsMsgDBView.cpp)

are we going to have to fix mime to output the color?

futuring, since this won't happen for 1.2 beta.

cc ducarroz (since it will involve mime, and jglick for UI, and putterman
Target Milestone: mozilla1.2beta → Future
I recently installed OE6, and can not find the darn settings for quote colors. :(
If i recall correctly, OE had a little graphical preview with identation to
illustrate what was being set. I looked (sorta) like this:

+- quote level colors -------+
| unquoted text [black  ]\/| |  
|  level 1      [navy   ]\/| |
|  *level 2*    [maroon ]\/| |    <-- selected
|    level 3    [green  ]\/| |
|     level 4   [purple ]\/| |
|      level 5  [teal   ]\/| |
+----------------------------+
| -----------                |
|  -----------               |
|  *~~~~~~~~~~~*             | <-- bold (= selected above)
|    -----------             |
|     -----------            |
|      -----------           |
+----------------------------+
|          [ Cancel ] [ OK ] |
+----------------------------+

Perhaps the bottom part could be considered redundant. :-\ Unless we want to
allow for n levels (in which case the top part _could_ run out of space on the
right.
Outlook Express does NOT color by qouting depth and thus nor does it have an UI
for configuring it.

Outlook however does.
I hope this clears up the confusion.

As far as the UI implementation goes I think we should reuse the Labels UI
design altered to show the levels indented like in Peter Lairo's ascii-art drawing.
Reusing the code for the Labels UI modified slightly should make for a very fast
implementation with a familiar look to it.

The bottom part that Peter suggests but have doubts about , I think we should
leave out.. at least for the time being.
Lets see how well it works with the simple version before we try a more
complicated version.

I think that the coloring that is applied to quoted text should also apply to
the qouting lines so they have the same color as the quote level.
Also on the same UI panel we could include a checkbox that enables/disables the
quoting lines.
*** Bug 117831 has been marked as a duplicate of this bug. ***
*** Bug 179578 has been marked as a duplicate of this bug. ***
Making Subject more "findable:
OLD: [RFE] Color message by quoting depth
NEW: UI to define multiple quote-levels colors (text & background)

Suggested UI:

+-- Quote-Level Colors ---------------------------------------------+
|                                                                   |
| Level 1: Text Color:[Blue  ] Background Color:[10% grey]     /\   |
| Level 2: Text Color:[Red   ] Background Color:[15% grey]     ||   |
| Level 3: Text Color:[Green ] Background Color:[20% grey]     ||   |
| Level 4: Text Color:[Purple] Background Color:[25% grey]     \/   |
| [More] [Fewer] [Reset to Default] [Remove all quote-level colors] |
|                                                                   |
| Preview:                                                          |
|   This is unquoted text                                      /\   |          
                    
|   | This is Level 1 Quoted Text |   |   |   |   |   |        ||   |
|   || This is Level 2 Quoted Text |  |  |  |  |  |  |         ||   |
|   ||| This is Level 3 Quoted Text | | | | | | | | | |        ||   |
|   |||| This is Level 4 Quoted Text ||||||||||||||||||        \/   |
+-------------------------------------------------------------------+

The quote bars ("|") should also be colored to coincide with the level it
belongs to.

Optional: If user selects (or hovers over) a line in the settings portion, the
corresponding line below is bolded to give a visual clue as to which quote level
will be affected.

There also needs to be a better way to select/define shades of gray. The current
color picker is not very good for this. Something where selecting these would be
easy: RGB(245,245,245), RGB(235,235,235), RGB(225,225,225), etc.

A good starting point for possible default values is given here:
http://texturizer.net/thunderbird/tips.html#app_quotelevels

This new pref would replace or augment the existing pref (from bug 219344):
+-----------------------------------------------------------------------+
| When displaying quoted plain text messages:                           |
| ( ) Use one setting for all quote levels                              |
|     Style:[Regular] Size:[Regular] Color:[Blue] Background:[10% gray] |
| (x) Use predefined multiple quote levels.                             |
+-----------------------------------------------------------------------+

BTW, notice how i added "Background" to the existing pref above? It would be
great if that setting could be added in the interim. ;)

(OT): Here's how to get the cool quote-level colors until this bug is fixed:
      http://texturizer.net/thunderbird/tips.html#app_quotelevels
Keywords: polish
Summary: [RFE] Color message by quoting depth → UI to define multiple quote-levels colors (text & background)
Nice idea (by texturizer.net) to color the background as well.
I think the new summary is harder to read. Reverting most of the changes.
Defaults etc. are part of this bug (another reason to revert the summary), bug
219344 is a dup.

I would try to avoid overly complex or large prefs UI. I would count e.g. the
last suggestion as such. There also once was a newsgroup discussion on
nmp.mail-news about the prefs UI.
URL: http://nnr.freeservers.com/cgi-bin/i/... → http://texturizer.net/thunderbird/tip...
Summary: UI to define multiple quote-levels colors (text & background) → Color message by quote depth/level
*** Bug 219344 has been marked as a duplicate of this bug. ***
*** Bug 219344 has been marked as a duplicate of this bug. ***
There's NO NEED for a UI for this. At all.

1. This is a great thing to turn on by default.
2. Specify SOME useful quote-level colors in whatever .css file. 
3. Watch praise come pouring in from Mozilla reviewers.
4. If somebody (other than Peter Lairo!) actually does complain after this is
released, examine the complain on its merits.
5. You can always make it possible for theme authors to modify these colors!

I predict that VERY few people will actually complain about the chosen colors,
but the colors have to be chosen carefully from a usability point of view. 

0. The actual colors are arbitrary. 
1. The selected colors for each level should emphasize contrast, so that level 1
looks as different as possible from level 2.
2. The selected colors should be sensitive to color blindness, so no defining
red for level 1 and green for level 2 (nor colors that contain red for level 1
and colors that contain green for level 2). For more, see
http://more.btexact.com/people/rigdence/colours/.
3. Don't forget that you can use black (or whatever the default text color is in
the e-mail) as a color that's one or two quote-levels removed.
The idea of coloring quote-levels per default is good. I also have no problem
with providing sensible defaults that can't be changed (surprize!). However,
there should, at a minimum, be an *easy* way for users who hate it (and there
will be many) to turn it *off*. So here is, IMO, the minumum UI we need:

 [x] Color quoted text

Since background colors (shades of gray) are another cool feature that will have
strong love/hate followers, this *could* also have an on/off switch.

 [x] Color quoted text
     [x] Also color the quoted text's background (shades of gray)

PS. I noticed that the current pref says the pref is only for "plain text". But
tested it with an HTML e-mail, and the text/background coloring worked there too
(see attached screenshot). Maybe the pref should be edited. Another bug?
Screenshots:
(1) the setting (notice is says "plain text")
(2) test HTML e-mail (notice the text & background colors)
(3) source code of e-mail (in case i overlooked something)
Peter Lairo, are you sure that you aren't confusing your own userChrome.css
modifications with the pref for coloring plaintext quotes? I confirmed in the
code that the latter pref is only used for real plaintext and format=flowed.
It's a different bug in any case.
I'd propoose the following route of action for now:
- remove the legacy plaintext quote style prefs (dragged over from the 4.x
  feature set / code). It doesn't really make sense in Mozilla, because we
  can format all quotes, not just plaintext.
- Add the "[x] Color quoted text" pref Peter Lairo suggested (default on).
  This would enable the "color by quote level" feature proposed here.
- Do not offer a way to change the colors yet.

I believe this is reasonably easy to implement (I'd volunteer) and actually
removes clutter from the pref UI.
It does change the feature set somewhat - removes a few choices which I think
don't make too much sense (only plaintext), but adds this cool feature. I
believe that the bolding/size change doesn't have too many followers. Users
won't have any way to change the quote color anymore, which may upset some
users. If the backslash is too bad, we can add a button "Adjust colors" next to
the checkbox, opening a dialog which allows to change the colors by quote depth.
"We" in this case would not mean "me", though - I have no intention to implement
that dialog. It may also get ugly code-wise, not sure.

mscott, Seth, what do you think?
> Users won't have any way to change the quote color anymore, 
> which may upset some users.

Would they be able to override the built-in setting by editing their userChrome.css?

What will happen with existing profiles? (hopefully, turn ON quote colors)
Peter Lairo,
(he just mail me and confirmed that he was indeed confused in comment 28)

Yes, the setting should be overridable in userChrome.css. Or you can disable the
pref and still use your current userChrome.css with a result identical to now
(if it works the way I have in mind).

It should apply to HTML, real plaintext and format=flowed.

Default pref changes take effect in existing profiles, that's how the prefs
system is designed.
As the bugs original reporter and also as a colourblind person I feel I should
grace you with my comments.

#30 Ben , I agree with that course of action.
The important thing is to get this feature implemented .. having a UI for
setting the colours was just intended as a "nice" thing.
Peter Lairo was indeed wrong in his original asumption that this bug was for a
UI .. I didn't intend it that way.

The original idea was :
Step 1) - Implement feature
Step 2) (optional - could be left out) - Make UI to allow modification of the
colours

I can see how keeping it simple would be a better thing for majority of users.
As long as we have the ability to alter the colours in a file, the powerusers
that like to tinker with the settings can be satisfied too.

You have my blessings to go ahead with any action that will bring an
implementation to Mozilla fast .. it's been almost 2 years since I suggested
this and its such a nice and visible feature that could help convert OE users.

#26 I would agree on most of the arguments in that entry too , but I would
probably suggest a more relaxed aproach to pleasing the colourblind part of the
population.
Most colourblind people can tell the difference between red and green , only
very extreme cases can't.
They differ from colournormals in that they have reduced sensitivity to a
specific colour - In most cases and in mine : green.
It's a common mistake for people to think that colourblind people can't see
colours at all or can't see a single colours at all.

As long as you choose bright vivid colours, you should be fine as it's the weak
shades of a colour that can be mistaken for another.
When i doubt you can use the VisCheck pages to simulate certain types of
colourblindness on a particular image or webpage with images :
http://www.vischeck.com/vischeck/vischeckImage.php

There are some examples of images processed here :
http://www.vischeck.com/examples/
They give you a good idea of what colourblindness is.

If it causes no problems you could do as you describe .. not putting green and
red next to each other (blue could be inserted in between) - that might help the
extreme cases.
Still even for a completely colourblind person (monocromatic vision) the shades
of grey on the background will indicate the difference in quotelevel .. as will
the quotebars.

I'd be happy to test and ok any implementation for problems with red/green
colourblindness compatability.
*** Bug 219344 has been marked as a duplicate of this bug. ***
I just noticed today that there is a Thunderbird extension out called
Quotecolors that implements this bug and a UI for it.

http://quotecolors.mozdev.org/
If its good enough it may be that we could adopt it as a fix.
In any case its interesting.

I also noticed that bug 152144 (quoted text color is hard-coded, conflicts with
dark color schemes) is related to this bug.
Any implementation should have both theese bugs in mind.
FYI: Colored quote bars (unfortunately, no text and beckground, yet) have just
been implemented in Thunderbird in bug 245196. Maybe you guys can _join efforts_
to fully implement colored quote bars, texts and backgrounds. ;)
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Status: ASSIGNED → NEW
*** Bug 300810 has been marked as a duplicate of this bug. ***
With official development on the Seamonkey suite gone, shouldn't this bug be
retargeted to Thunderbird ?
No, it's still a valid SeaMonkey bug.
Duplicate of this bug: 342008
QA Contact: esther
Assignee: mail → nobody
QA Contact: message-display
Target Milestone: Future → ---
See Also: → 851022
Component: MailNews: Message Display → Message Reader UI
Product: SeaMonkey → Thunderbird
Duplicate of this bug: 851022
So is this for Thunderbird or Seamonkey?
BenB, what is the state of the implementation you offered to do?
This bug was opened for the Mozilla Suite which eventually became SeaMonkey. Its implementation of the message viewer is separate from Thunderbird's versions, specifically (but not exclusively) as far as display styles are concerned. The fact that some bugs for Thunderbird have been duped to this one lately doesn't change that these are separate applications which each needs its own fix for this.

Thus, let's keep this for SeaMonkey and use the bug 851022 for Thunderbird. Obviously, the fix for one can be used by the other with adaptions.
URL: http://www.mozilla.org/support/thunde...
Component: Message Reader UI → MailNews: Message Display
Product: Thunderbird → SeaMonkey
Whiteboard: [please dupe TB bugs to 851022]
The requested feature is the same. The main component here is libmime and shared between both applications. The fix would be the same. The only difference between the apps might be the preference UI, but I would suggest to share that as well.

I just don't like to have 2 bugs for (almost) the same thing, it hides valuable comments like here above. It's disruptive.
If a solution based on libmime is needed (bug 851022 comment #10 had a different solution by selectively including a CSS sheet or not), it would/should only add attributes for the quote level and/or another attribute whether or not it's supposed to be colored based on the current pref value, you'd still need the application-specific CSS definitions to actual apply the desired color.

> I just don't like to have 2 bugs for (almost) the same thing

I was mainly objecting against hijacking a SeaMonkey bug for Thunderbird just like that. If you want to fix it in libmime rather than by selective CSS sheets, this should be moved to MailNews Core to define the backend. We could still use bug 851022 in this case to define the actual color scheme to be applied for Thunderbird.
If you stop generating some attributes in mime when the coloring pref is off you make users unable to apply their own styling from userChrome.css.
I don't know which solution Ben has in mind, this was just a guess. This would be an additional attribute (again, thinking loud) that libmime produces and adds to the blockquote when the pref is enabled, to trigger the built-in rules. Thus, you could trigger that rule either based on its existence or use your own colors from userContent.css; ideally, the same definitions you have now would keep working after adding this.
rsx, that's exactly what I had in mind, yes. :-)

The way prefs are handled currently is: libmime reads prefs in C and sets DOM element attributes based on that, e.g. "colorquotes=yes" (logical, not concrete presentation). Then, the stylesheet sets the concrete style. We can do the same here, it's 3 lines of C code plus the stylesheet in comment 14.
If that works for HTML messages as well (i.e., inject the attribute into the blockquote nodes already created from the text/html part) that version looks cleaner to me than switching off the stylesheet based on the preference.
BenB, so could you make some patch now? At least from TB side we have UX confirmation that this should be accepted.
You need to log in before you can comment on or make changes to this bug.