message headers spaced further apart (2.0a1 vs 1.5.0x) I'm seeing more space in between the subject, from, sender, date headers in the message pane. screen shots coming...

trunk seems to be like 2.0a1. Is this considered a good thing (tm) or how should it be? I actually like it that the lines don't stick together too much.

weird, I don't see this on Windows.

> weird, I don't see this on Windows. I think I know how to reproduce this. Go to display properties, the Appearance tab, and switch from Normal to Large Fonts under "Font Size". With large fonts, 2.0a1 will look different than 1.5.0.x. But under "Normal", they look the same.

20060802 is the same. No problem with this. I like it. No need for Large fonts. o_O

Looks like bug 335973 probably caused this.

(In reply to comment #8) > Looks like bug 335973 probably caused this. (In reply to comment #27 from bug 335973) > screenshot - SM after with .headerName, .headerValueBox {margin-bottom: 0 > !important;} in userChrome.css So this is all that need to be done to restore previous behavior I still don't understand why this bug is open ... no comment shows which style you prefer... > I like this much better, but would prefer bug 9942 be fixed.

I use Large Fonts under Windows 2000, I see this with 3a1-0804, and I would prefer the more compact display of previous builds.

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

Also on linux, and osx per bug 345789 comment 0. tm from bug 345789

I put .headerName, .headerValueBox { margin-bottom: 0 !important; } in userChrome.css to rid the excess space from SM on 21 July, shortly after bug 335973 fix was checked in, so it seems somehow this and 335973 must actually be core.

space, the final frontier :) I don't see this as a matter of style or asthetics: a) there are no bugs filed that lines be put closer together, b) if bug 335973 is the cause, intentional or not, doing more than improving the presentation of "e-mail addresses" is beyond the bug's scope, and finally c) it's just _wasting_ space - spacing needs to be more compact (also affects trunk of course)

Scott requested a larger margin in bug 335973 comment 17.

(In reply to comment #15) > Scott requested a larger margin in bug 335973 comment 17. (saw that) and then tested with other font sizes?

I agree there's too much space when running with large fonts on windows. I think we nailed it for regular fonts on windows, but I didn't test large fonts at the time.

Neil, what do you think of something like this? This makes the padding between the addresses fixed at 5px instead of something that scales with the font size. There's still a little bit more padding than there was in 1.5 for large fonts, but it's better than it is today and I think the little bit of padding is fine. Normal fonts still have the right amount of padding. Any smaller,and normal fonts start to suffer from being too cramped I think. If this looks like the right idea to you, I'll make a patch that fixes the seamonkey theme too.

Comment on attachment 252942 [details] [diff] [review] [fixed branch and trunk]possible fix Neil see comment 18 :)

as promised, here are the same CSS changes for the suite.

fixed branch and trunk.

Wayne, since you were seeing this on Windows it would be good for you verify it as well in tomorrow's build.

SM has not improved AFAICT, modern and classic themes. TB no improvement - default theme

(In reply to comment #23) > SM has not improved AFAICT, modern and classic themes. > TB no improvement - default theme Really? I see a clear improvement in both SM and TB trunk. However, I've decided 5px is still too wide and have implemented a 2px margin in my userChrome.css. My userChrome.css has this now, which is applying the margin slightly differently than seen in the patch: .headerNameBox, .headerValueBox { margin-bottom: 2px !important; } .headerName { margin-bottom: 0 !important; }

Scott, I suggest the patch be changed from 5px to 2px oops, retest because I made a mistake - discovered I installed 20060109 into 0130 directory :( haven't made that mistake in a long time. yes TB is improved, but Mike's 2px is far better. for a 5 line header on my display the header height is 1-3/8", 1-1/4" and ~1" respectively for 5em, 5px, 2px. so a gain approaching 1/2" which is fantastic. SM was tested on w2k, I don't have winXP results ATM.

My testing showed, 2px didn't leave enough spacing for normal sized fonts, things looked pretty compact. I think 5px seemed like a good compromise for both. yes it takes a bit more space than it did in 1.5.0.x for large fonts, but it's a lot less than it was in beta 2 and I thought it looked nice.

I'm running with 2px again at Normal fonts and it is pretty compact, but I could possible be talked into it. Mike, what do you think of 2px at normal fonts?

OK, I switched over to small fonts for testing [I can't *believe* that requires a Windows reboot]. Oddly, the 2px margin looks a little more cramped at 96dpi than at 125dpi -- does Mozilla scale "px" according to dpi? (I believe CSS calls for this, so I wouldn't be surprised if that's how it's done.) The worst part is right along the bottom when the last header line is To: -- the underline of the address is almost flush with the border between envelope and message pane, makes that boundary look too busy. So, I'd say stick with the 5px for the default. This is an easy enough customization.

.headerNameBox, .headerValueBox, .headerName { margin-bottom: 0 !important; } same result using the following: .headerName, .headerValueBox { margin-bottom: 0 !important; }