4.x mac would underline the subjects (maybe more) of collapsed threads that had unread messages. we should do this in the 6.x classic mac skin. should we do it in modern?

I think this should belong to andreww or hewitt?

No, this isn't a themes issue, it requires marking some attribute in content to indicate a descendant message of a thread is unread. Not sure if this is being done yet. If it is, then it becomes a themes issue.

64477 touched on this topic. Using underline for collapsed threads with unread children seems like a good idea for all platforms/skins. /And doing away with the green arrow since the green arrow is used everywhere else to mean "newest" (not "unread"). Thoughts? From 64477: ------- Additional Comments From mpt 2001-01-18 10:03 ------- Underlining doesn't look unread, but gets the `this thread contains unread messages' idea across much better than just the green arrow does. Try 4.x for Mac sometime -- it's groovy. ------- Additional Comments From jglick@netscape.com 2001-01-18 10:42 ------- I think using the bolding is bad because the parent message isn't unread. I also think changing the icon to have the green arrow is bad because we are using the green arrow in Mail to mean "Newest" messages (which is also unread, but unread doesn't always equal "newest"). Underlining seems to work ok.

I like the 4.x mac style of: text fields (subject, date, sender, etc) of closed threads with unread are underlined. the fix will take me a minute, please update the spec (and add a link to it) if you want me to do it. I'll make modern and mac classic do it. are you sure you want this for unix / win classic? I'm ok with that decision, but I'm not sure if the goal of classic is to exactly match 4.x or not.

note, right now we don;t bold the parent if the parent is unread (and has unread children). so we are doing everything right except for the underline. fix on the way.

>are you sure you want this for unix / win classic? I'm ok with that decision, >but I'm not sure if the goal of classic is to exactly match 4.x or not. Would like to hear others opinion on this one. If we did something on one platform for 4.x that people think was a good idea, I don't think its a problem to incorporate it on all platforms for classic (as well as other skins). Joe, is classic trying to duplicate 4.x exactly for each platform?

i'd like the underline although i think it does conflict w/ the definition of classic.

The original intent of Classic wasn't to mimic 4.x in every regard, its original designer (Ben) has said so himself. It was more of an "embrace and extend" technique. That said, Outlook Express just bolds the thread titles, and I like that best (I can see lots of underlines making it hard to read, and the bolding is consistent with read/unread email messages...). I can understand the arguments against that, though (the parent message has been read, but is still bold). cc'ing other usability people for their input

so, let's just go w/ a class that can be styled in userChrome.css.

The fact that 1% of users can change this if they know how to edit their userChrome.css file shouldn't play a role in this usability decision at all...

my part of the fix for this is in. blocked by #74663 (underlines don't show up in the outliner)

since "underlined" will indicate if a thread has unread children or not, should the icon in the thread column only show the green arrow if the thread contains any "new" messages? note, 4.x linux showed the green arrow if the thread contained any unread.

>since "underlined" will indicate if a thread has unread children or not, should >the icon in the thread column only show the green arrow if the thread contains >any "new" messages? The "green arrow" is used everywhere else in the app to mean "newest" mail, not "unread". If we want to be consistent with that the threaded icon should follow this also. >note, 4.x linux showed the green arrow if the thread contained any unread. I believe 4.x Mac and Win did also (but that doesn't mean it was right).

I agree that getting rid of the green arrows in the message pane would be a good thing. Does anyone have a screen shot of 4.x mac in threaded mode. As a Windows user who hasn't seen this yet, I feel like all of the underlines might make the screen even busier than it already is.

the underlines are a nice touch, I think you'll like them. once we have them, it will be a snap to fix it so the green only shows in the thread column thread pane if there are new messages in the thread.

ok, no need for a screenshot. This appears to be working already. At first glance it seems a little strange to me, but I could get used to it.

getting a mac 4.x screen shot now...

Actually, I think this looks really good for threads that aren't consecutive. It only looks strange to me now when you have a whole bunch of collapsed threads next to each other. Anyway, as I said before, this is working for me in modern on 20010404 on Win 2000

it wasn't working for me on linux. but I'll wait until my build is done to make sure. it could be related to the other possible issues we have with outliner and fonts (with desenders not showing up.) since it works somewhere, we can mark this fixed and then change 74663 to be a linux issue.

since this works in w2k, I'll mark this fixed. I'll start a new bug to discuss not showing the green arrow in the thread icon column unless the thread has new messages.

see #74663 for the platform specific issues with "underline" not working.

SS: Where was that new bug?

skewer, the bug you want is bug 58788 [#74663 was marked a up of that].

Er, not that one. The one about the new icon and underline appearing on threads that didn't contain any new messages.

I'm not seeing the underlines anymore in 2001060504 Win98. I won't reopen this unless someone else can confirm (mainly because I think these are kind of ugly and may have intentionally been removed, and are not needed with the green "new" arrow icon).

Note that I know why underlining only worked on Windows, and I actually patched the text decoration painting code for nsTextBox when I landed 78695. Outliner needs to have the same patch applied, and then underline and strikethru and overline would all work on all platforms.

Build 2001-06-18-04: WinMe Build 2001-06-18-08: Linux RH 6.2 Build 2001-06-18-05: Mac 9.04 Reopening since the underline is not appearing for threads with unread children.

nbaca, had this ever worked for you on win32? just curious... anyhow, the [other] platform issues are covered in bug 58788...

note, this works on win2k (or did at one point.) I think it still does, but that might be display specific. I need to follow up with hyatt about how to fix it. hyatt wrote: "Note that I know why underlining only worked on Windows, and I actually patched the text decoration painting code for nsTextBox when I landed 78695. Outliner needs to have the same patch applied, and then underline and strikethru and overline would all work on all platforms." accepting until it is fixed in a way that works for all displays.

Using a build from a couple of days ago on Win 2000, this no longer worked.

I saw this working at one point too, on Windows. (This would explain why I tried to use text-decoration: underline in another outliner and it didn't work...)

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

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

If we're at it (underline has problems), maybe it would be better to use bolding instead. If you argue that the parent message is read and only some children are unread, then we might use bolded text of dark grey color (so that it looks like "dimmed" black bolded text). It means "some but not all children included" in similar contexts - for example in different installers that allow hierarchical package selection (MS Office, Linux distros, OpenOffice...). Given that underlining doesn't currently work it's _very_ hard to tell what threads are unread. The green-arrow thing is something counter-intuitive. I consider myself a power user, and I didn't notice it meant "unread thread". I discovered the green arrow only when I started to search for this bug on bugzilla... I was actually looking for a bug that would say "Collapsed unread thread isn't bold"... Anyway, since: 1. that bug has been unresolved for such a long time because of decorations not quite working on all significant platforms 2. it still can be argued whether the underline stuff won't just confuse the majority of both Outlooks users ...maybe we should do it the 95%-of-users-expected way, that is the way it is in Outlooks. At least temporarily. This should be simple, shouldn't it?

Gray is universally recognized as the "disabled" color in Windows. Furthermore, you have to be careful that in such an instance you choose an OS- or skin-appropriate color. Obviously if all my windows have gray backgrounds with white text, gray text is a bad idea.

I vote for bold. I think that when we implement the labels feature, the bolding might make more sense to a user as opposed to underlining.

FYI - Labels: 81292

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

win32 build 2002011703, win98se Up until sometime around this build, collapsed threads with unread children had no special styling, at least on Win98. They are now underlined. This pretty much sucks when the view is Threads with Unread - virtually every thread is underlined and, IMO, seriously impairs readability of the threadpane. Some folks must think this styling is beneficial, or it wouldn't have been implemented in the first place (whoever put the comments in threadPane.css thought it was "slick", but that's a matter of opinion). I ended up turning it off completely in userChrome.css because most ngs I frequent are in Threads with Unread, and I had serious difficulty reading the threadpane with all the underlines. A color property would be much easier on the eyes. Underlines stink.

Is this really a nsbeta1+, P2? If yes, then we need to try and targeted to a milestone M1.0 or earlier to make the beta.

<quote src="news://news.mozilla.org/3C486ADA.5050507@beonex.com" author="me"> Arg! Please don't use underlines *anywhere*. underlines are an ugly leftover from typewriting machines. Please use italics, bold, color, whatever, but let us forget underlines forever. </quote> Bold usually means unread. For me, it would make sense, if collapsed threads with unread were bold, because that top-level post then stands for the whole thread. As soon as followups are visible, the bolding of the top-level post depends on if that post itself has been read. If we would allow subthread to be collapsed, the same would apply to them.

There is one problem with my suggestion: The user can't see anymore, which threads he started to read (but didn't finish or which have new posts). Maybe Aleksander's suggestion in comment 34 is a good idea. > Gray is universally recognized as the "disabled" color in Windows "There are different shades of grey". ;-P Seriously, disabled is some mid-grey, while Aleksander spoke about dark grey. It is quite possible to differentiate them.

I like Ben's idea for using bold. As for how to indicate which threads have unread children... There's an icon next to the subject, which indicates newly downloaded messages with a little green arrow. Why not add a third state to that icon to indicate whether or not a message has been read? (in addition to going from bold to non-bold). A collapsed thread with unread children will have an icon that indicates that the message is read (if the parent is indeed read), but it will be bold, indicating that there are unread children. I realize that it's very Outlook Express-ish, but the concept works well.

You can test this easily: - create <profiledir>/chrome/userChrome.css - add the following lines: ----------- outlinerchildren:-moz-outliner-cell-text(container, closed, hasUnread, read) { text-decoration: none !important; color: darkgrey !important; font-weight: bold !important; ----------- To my eye there does not seem to be a good shade of dark gray for this: either it is - too dark to be distinguishable from black & bold - too medium so that it is not too distingushable from black & normal-weight - too light so it's, well, light, and rather disabled-looking perhaps Anyway, the underline is not nearly as messy as I'd thought it would be, it actually looks neat, and is symbolically logical (stuff [unread] _under_ this one).

I found that a color property does not always work well. outlinerchildren:-moz-outliner-cell-text(container, closed, hasUnread, read) { text-decoration: none !important; color: darkgrey !important; (or any other color of your choosing) When the top-level message in the thread is selected and there are still unread children, the subject line in the threadpane is no longer readable against the background color of the selected message. If the threadpane loses focus, i.e. click in the message view pane, the selected message background color changes, but it may still be tough to read depending on the text color (gray on gray is not very good). This is likely to be more of a problem in Classic than Modern, due to the unknown color combinations used in system settings. If colors are used, may need some more styles to account for selected message in a collapsed thread with unread children.

That can be enhanced by adding new CSS rule: outlinerchildren:-moz-outliner-cell-text(selected, container, closed, hasUnread, read) { color: whatever !important; } Anyway, I vote for underlines.

IIRC Collapsed folders with unread subfolders are bold. This is a similar pattern to collapsed threads with new messages. So, bold for both please?

What about creating two meta bugs, first being "Collapsed threads with unread children should be bold", second being "Collapsed threads with unread children should be underlined", state in thoes bugs that voting will be over after, say, 3 weeks, and let people vote on one of those bugs to see which option wins?

The underlines look pretty good.

The underlines may look OK when the view is All threads, but, IMO, present a readability problem when the view is just Threads With Unread.

Could this bug depend on bug 59681? I mean, that Mozilla displays underlines although there are no unread children?

The CSS selector that currently works (in the thread pane, at least) is: treechildren::-moz-tree-cell-text(container, closed, hasUnread, read) which is slightly different from the selector presented in comment 46; I don't know whether that one has been obsoleted. The 'selected' attribute seen in that older one may be added to the parenthesized list if a different appearance is desired when the node is selected. I turned the testcase from bug 58788 (which this bug depends on) into an attachment there, making it a little easier to verify whether it's been fixed; the outstanding problem being mentioned had been (three years ago!) for XUL text-decorations under Linux. Other than that, the use of underlines has become pervasive; all the themes I've tried in Mozilla, and the default TB theme, use them. Is making these bold instead still an issue? (Maybe so -- there was just recently a request in the newsgroups to use bolding, which is what led me to this bug.) (In reply to comment #47 [Neil]) > IIRC Collapsed folders with unread subfolders are bold. This is a similar > pattern to collapsed threads with new messages. So, bold for both please? True about the folders, but: folders also show a count of unread items, while a collapsed folder with nothing unread on its own simply shows bold. So, there's still a simple way to distinguish between "visible item is/has unread" and "only visible item's subitems are/have unread".

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420

This is WFM for a long time now.