71539 - Don't default to Helvetica on Mac

Status: VERIFIED WONTFIX

(Toolkit :: Themes, enhancement)

Description

[marlon bishop]

In general, the Helvetica typeface which ships with all MacOS systems is not
suitable to onscreen display.  We had the same problem in themes which were
assuming that Helvetica would be fine for the chrome San Serif selection.  I
would suggest defaulting the Mac to Arial.  Not sure if there aren't any
crossplatform issues with this

other bugs related:

46415
23009
47510
47059
5236

Comment 1

[marlon bishop]

simplifying summary...

(variable-width san serif font setting should not default to Helvetica)

Comment 2

[marlon bishop]

see URL as an example of what happening

Comment 3

[Paul Chen]

Reassigning to hangas for UE's take on this

Comment 4

[hangas]

German and I approve the change.  Sending bug to Marlon to confirm that 8.5 
included the Arial font.

Comment 5

[marlon bishop]

On the mac, Arial exists only if the user performed the default MacOS installation..  If the user customized their intallation of MacOS, to not install IE, then they will not have Arial.  For this reason we should probably resort to Geneva.  

However, since the time of Helvetica, Times, Courier alot of improvements have come along in on screen font display.  On the Mac there are now other options which come by default with the MacOS.  I would suggest the use of Verdana as the San Serif font by default.

Ideally, if we were able to ask the system for a font, the way CSS rules would allow a font-family to be specified, then we could ask for fonts in this order:

Verdana, Arial, Geneva, Helvetica

similarly we could ask for improved Serif Font selections in the order of:

New York, Georgia, Times

for monospaced font:

Courier New, Courier

These 3 font changes would dramatically improve athe overall appearance of text display and layout.  If we're not capable of specifying families then the following selections would suffice:

Verdana
New York
Courier New

Comment 6

[Avi Rappoport]

Geneva is better, Arial is not on all Macs and it makes them look like bad
Windows clones.  Similarly, I prefer New York and Monaco for serif and
fixed-width fonts.

Comment 7

[marlon bishop]

we're already using Geneva for UI features. we need a different, grotesk typeface 
for default san-serif specified content.

Arial comes by default thanks to IE. In the instance where people modified their 
installation to not install "internet stuff", or, they customized "internet 
stuff" to not install IE, then they would not get Arial, true.  However we should 
be willing to look for Arial and never Helvetica.  That's all i am saying.

Comment 8

[marlon bishop]

reassigning to default

Comment 9

[Joe Hewitt (gone)]

Mass reassigning my theme bugs to Shuehan.

Comment 10

[shliang]

we are currently using system fonts, helvetica is not hard-coded

Comment 11

[Simon Fraser [no longer active]]

We actually hard-code "sans-serif" for window and other system fonts on Mac:

http://lxr.mozilla.org/seamonkey/source/gfx/src/mac/nsDeviceContextMac.cpp#278

This should be fixed.

Comment 12

[Simon Fraser [no longer active]]

Pierre: why this hard-coding to "sans-serif", and the whacky scaling?

Comment 13

[Simon Fraser [no longer active]]

Pierre: see also my comments in bug 102224.

Comment 14

[Pierre Saslawsky]

We are dealing with different problems here:
1) Some CSS3 fonts are defined as sans-serif instead of their proper system 
equivalent ("define proper?") in order to preserve the compatibility with MacIE5, 
especially in strict mode (see bug 3371).  Not being compatible, IMO, would have 
made the CSS3 fonts unusable on the Mac.
2) The issue of not using Helvetica, and other issues related to the default 
fonts, are covered in bug 61883.  I attached a draft patch several months ago 
that allowed to specify font prefs similarly to a CSS font-family (eg "Verdana, 
Arial, Geneva, Helvetica").  The bug then moved to other people.  I'm not sure 
anything was checked in.

I'm keeping this Mac-only bug opened instead of marking it dup of XP bug 61883 in 
order to set the default prefs on the Mac.  Marking dependency.

Mac folks: what is your vote for the 5 basic CSS fonts?

Comment 15

[Simon Fraser [no longer active]]

>1) Some CSS3 fonts are defined as sans-serif instead of their proper system 
equivalent ("define proper?") in order to preserve the compatibility with MacIE5, 
especially in strict mode (see bug 3371).  Not being compatible, IMO, would have 
made the CSS3 fonts unusable on the Mac.

Is this the reason for the code at 
http://lxr.mozilla.org/seamonkey/source/gfx/src/mac/nsDeviceContextMac.cpp#278
?

The problem with doing this is that it prevents skin authors from making proper 
use of system fonts in the chrome. I would argue that it's pretty important, from 
a skin author perspective, that eSystemFont_Window maps to kThemeSmallSystemFont.

Comment 16

[Pierre Saslawsky]

Yes, the compatibility with IE is the reason for this code.

Assigning sans-serif to some of the CSS3 fonts was required in Mozilla to 
preserve the look of the UI across platforms.  For instance, 'button' and 
'pullDownMenu' are defined as sans-serif (instead of kThemeSystemFont in MacIE5) 
otherwise they would have been displayed in Chicago or Charcoal and the controls 
would have been much bigger on Mac than on other platforms or even on MacNav4. 
For 'window' and 'document', it is more debatable.  The reason for choosing sans-
serif was only the compatibility with MacIE5.  

Changing it would raise several questions:
- What meaning do we attach to 'window' and 'document'?
- Can't we stick to CSS2 fonts in the themes? 
- Shouldn't we be using only well-defined '-moz' fonts everywhere in the themes 
(as we did for 'tooltips' and 'widget')?

I'm not sure 'window' should be mapped to kThemeSmallSystemFont because I don't 
really know what 'window' means.  If I had to choose, I would go with additional 
'-moz' definitions that cover all our needs for the UI in order to separate 
issues related to the chrome (that are internal to Mozilla) from issues related 
to the content area (where compatibility matters the most).

shliang & others: Do you agree?  How difficult would it be to convert the fonts 
within the chrome from CSS3 fonts to some new '-moz' fonts?  How many different 
fonts do we use in the chrome?

I can do the work of providing the new '-moz' fonts.

Comment 17

[marlon bishop]

since themes can't bundle their own fonts, i don't think it's too much trouble that 
theme authors wouldn't be able to specify their own typeface for content.   
it would be great if they could, but i'd rather we have a legible default 
typeface.

verdana, arial, geneva, for sans
New York, Georgia, Times New Roman, Trebuchet MS, Times for variable width font
Courier New, Courier, Monaco for monospaced

Comment 18

[Simon Fraser [no longer active]]

Can we get some action here? Reminder: the bad code is at:

http://lxr.mozilla.org/mozilla/source/gfx/src/mac/nsDeviceContextMac.cpp#278

Comment 19

[Simon Fraser [no longer active]]

> The reason for choosing sans-serif was only the compatibility with MacIE5.

The problem with this code is that affects all of Mozilla (including skins), not 
just form controls.

Why didn't we solve the problem with some mac-specific forms.css style?

Comment 20

[Pierre Saslawsky]

>Why didn't we solve the problem with some mac-specific forms.css style?

If we do it that way...
- Web applications that customize their form controls will have to provide a 
special stylesheet for the Mac clients.  If the CSS3 fonts defined in GFX don't 
fit our needs for our own form controls, they will probably not fit the 
customers' needs either. 
- It would not be coherent for a web application to declare "font:field" and get 
a different font than the one we use in text fields because we have overriden the 
declaration for the INPUT element in the Mac version of forms.css.

There are 2 different bugs here (see comment #14) and at least 4 constraints:
- compatibility with Nav4 (see related bug 53617)
- compatibility with IE
- aesthetics (buttons in kThemeSystemFont look quite big compared to fields in 
kThemeSmallSystemFont and lists in kThemeViewsFont, unless the buttons are used 
for OK/Cancel in dialogs)
- existing css files for skins and forms

A temporary solution for the original bug is to change Helvetica to Geneva in 
macprefs.js.  Then I'll do the implementation of bug 61883 on the Mac and the 
prefs will become what Marlon wrote in comment #17.

A solution for the problem you reported is to remove the ugly code from gfx but 
move it to http://lxr.mozilla.org/mozilla/source/content/base/src/
nsRuleNode.cpp#1708 in order to preserve the compatibility with Nav4.  But then 
someone will have to check the existing skins for any breakage and also make sure 
that common pages with forms still look right (aesthetically speaking) when 
displayed in strict mode, which may not be obvious given the problem I mentioned 
above.

In terms of aesthetics and preferences, I'm not sure the Document and Window 
fonts should be mapped to kThemeSmallSystemFont as you said.  I could go either 
way but it seems more natural to me that these fonts be mapped to the default 
proportional font in the prefs panel, which is also the choice made by IE.

I am much more concerned by ugly pages than by ugly code.  The current code at 
least keeps a pleasant ratio between form controls and the rest of the page in 
strict mode and quirks mode.  Of course, there are other combinations of fonts 
and sizes that would produce a pleasant ratio too but it would require breaking 
the compatibility with Nav4 and adapting forms.css on all platforms (for 
instance, to use DropDownMenu instead of List).  The compatibility with Nav4 
should be debated under bug 53617.  Marked dependency.

If you have other reasons to remove the ugly code, please list them here (you 
mentioned some skins that don't render well). I may file a separate bug for that 
because the Helvetica vs. Geneva issue should be dealt with separately.

Comment 21

[Pierre Saslawsky]

Attachment: use geneva instead of helvetica

Comment 22

[Simon Fraser [no longer active]]

I think the real solution is one you mentioned above; define new _moz CSS 
attributes for skins (_moz_window, _moz_button etc) which will allow skin authors 
to use the correct fonts for UI elements (see bug 102224), and keep the CSS 
'window', 'button' etc. attributes for web content.

Comment 23

[Pierre Saslawsky]

I opened bug 109439 to add several -moz fonts and resolve skin issues.

This bug is now for the Mac implementation of bug 61883 (ie. 'font-family'-style 
font lists in macprefs.js) and other content issues that will probably be forked 
into another bug later (such as: do we remove the ugly code? what about IE and 
Nav4 compatibility?).

Comment 24

[Kevin McCluskey (gone)]

Moving to Mozilla1.1. Engineers are overloaded with higher priority bugs.

Comment 25

[Steve Dagley]

This bug is a blocker for #84721 which is an nsbeta1+ bug with a TFV: mozilla1.0
therefore this bug can not have a TFV: mozilla1.1.  And with pierre having left
the company to ride his motorcycle around the world it needs a new owner. 
Please give it the needed luvin'.

Comment 26

[Kevin McCluskey (gone)]

Pierre's comment "This bug is now for the Mac implementation of bug 61883".
61883 contains 133 comments! It's difficult to understand what the problem is
and the proposed solution. Could someone please summarize what needs to happen?

Marking nsbeta1-, until we get an explanation of what needs to happen. Please
clear the (-) once an explanation is provided.

Comment 27

[Kevin McCluskey (gone)]

-

Comment 28

[Kevin McCluskey (gone)]

Bulk moving Mozilla1.2 bugs to future-P2. I will pull from this list when
scheduling post Mozilla1.0 work.

Comment 29

[Kevin McCluskey (gone)]

Bulk moving Mozilla1.1 bugs to future-P2. I will pull from this list when
scheduling post Mozilla1.0 work.

Comment 30

[Simon Fraser [no longer active]]

cc:ing bryner. We need to fix this for XBL form controls on Mac.

Comment 31

[Frankie]

1 year later... Priority P2 and Target Future don't make sense together.
Helvetica is much less bad with Jaguar's smoothing, but there are better choices.

Comment 32

[Samuel Sidler (old account; do not CC)]

Shouldn't the default be Lucida anyway since it's guaranteed to be on all OS X 
systems? It's also what's being using by Apple (and other vendors) in native 
apps.

Comment 33

[Philip Chee]

Thunderbird references:
http://hg.mozilla.org/comm-central/rev/f98d46450428
Bug 465633 - Use better default fonts for messages. Use ClearType fonts on Windows Vista and above, Lucida Grande/Menlo/Monaco on Mac OS X, and DejaVu on Linux
(Warning lots of bikeshedding)

We might want the "Lucida Grande/Menlo/Monaco on Mac OS X" changes.
cc Mnyromyr and stefanh.

Comment 34

[Frankie]

15 years later, what needs to be done to get this bug patched and resolved?

If needed, I could write & submit a patch for /modules/libpref/init/all.js

Comment 35

[Stefan [:stefanh]]

Frankie,

I don't have a name, but in order to get some attention, you need to needinfo? a specific person.

Comment 36

[Justin Dolske [:Dolske]]

The browser's own UI defaults to the system font (which is Lucida Grande, until it changed to Helvetica in 10.10). If that's not happening in some specific place, please file a new bug with details.

Both Chrome and Safari default to Helvetica for "sans-serif". The metrics differ between the two typefaces, which means changes could have webcompat issues. And considering that OS X itself now defaults to Helvetica, it's perfectly fine to use on screen. I don't think this can of worms and bikeshedding is worth opening.