222876 - help content ignores specified font

Status: RESOLVED WONTFIX

(SeaMonkey :: Help Documentation, defect)

Description

[Christian :Biesinger (don't email me, ping me on IRC)]

In preferences/appearance/fonts, I specified "Serif" as my default proportional
font. help is ignoring that and displays a sans-serif font. it should respect
the pref.

tested in 2003101004

Comment 1

[Daniel Wang]

I don't think font pref applies to chrome:// files

Comment 2

[R.J. Keller]

It should.

Comment 3

[R.J. Keller]

Attachment: Patch

Comment 4

[[e-mail]]

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

I'm still seeing font-family in the patched file, that looks wrong. Also,
should we be specifying pixel sizes or relative sizes?

Comment 5

[R.J. Keller]

I kept using font-family for h1, h2, and h3 tags because those should be
sans-serif. I don't want to stip the style that much ;).

Can you note any specific lines you have problems with?

Comment 6

[[e-mail]]

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

OK, so how about leaving the font-size on all the elements too?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Er...  why are we setting pixel font-sizes, exactly?

Comment 8

[R.J. Keller]

yeah, we really should do em's.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Or even large/x-large/whatever....

Comment 10

[R.J. Keller]

I'm beginning to disagree with this bug. Help on Windows looks awful with the
serif font by default. Should the Help docs really looks like a normal HTML
document to the user?

Comment 11

[Boris Zbarsky [:bzbarsky]]

The help documents should be in whatever font the user finds most readable. 
That's all.  If our default font is not easily readable, we should perhaps
change it.  In the default prefs.

Comment 12

[R.J. Keller]

I can understand font size (which can be changed with Ctrl+), but I find that
the help documents are much harder to read and skim through with the Win32's
serif fonts.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Then we shouldn't have those fonts as our default fonts.

Comment 14

[R.J. Keller]

well, true, but many websites rely on them. Not many sites are viewed perfectly
in sans-serif font. Most of the time it causes font sizes much larger than that
which was intended for.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Hm?  At the same font size?  Or are you talking about perceived font sizes?

Comment 16

[R.J. Keller]

I'm meaning that 12pt sans-serif is larger than 12pt serif. On Linux, sans-serif
is the default on my system and I notice that website font sizes are so large
that they cause the layout to get messed up. On windows, serif fonts are used,
which are smaller, which prevents the layout from moving inappropriately.

If I were to use Times New roman on Linux, I don't see this problem.

Comment 17

[Boris Zbarsky [:bzbarsky]]

By "larger" I assume you mean "wider"?  Because it should be the same height...

Comment 18

[R.J. Keller]

yes, but back to the point:

I find the help documentation more appropriate to have a sans-serif font than a
serif font. It seems easier to skim and remember. I don't agree, however, to
having a set font size, but that is already fixed (through text zoom).

Comment 19

[Boris Zbarsky [:bzbarsky]]

Well, I have to say that I find serif font with maybe sans-serif (or somehow
else clearly marked) headings much easier to skim.... (since the headings then
jump out at me).

Comment 20

[R.J. Keller]

sure, I'm cool with having the headings sans-serif. I'd also like the Section 
TOCs sans-serif as well. Think this will help with readability, bz?

Comment 21

[Boris Zbarsky [:bzbarsky]]

It may, sure.  No problems here with styling headings in a "not-normal" font,
since that's the whole point.  ;)

Comment 22

[R.J. Keller]

Moving to new Help component owner.

Comment 23

[R.J. Keller]

This bug should be WONTFIX to me. If we respected every pref a user set for
font, the help documentation would be nothing more than HTML with no styles,
which looks really bad. We need to keep a professional look in the Help
documentation.

Comment 24

[Robert Kaiser]

MASS-CHANGE:
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