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

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

see URL as an example of what happening

Reassigning to hangas for UE's take on this

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

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

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.

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.

reassigning to default

Mass reassigning my theme bugs to Shuehan.

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

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.

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

Pierre: see also my comments in bug 102224.

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?

>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.

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.

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

Can we get some action here? Reminder: the bad code is at: http://lxr.mozilla.org/mozilla/source/gfx/src/mac/nsDeviceContextMac.cpp#278

> 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?

>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.

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.

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?).

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

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'.

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.

-

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

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

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

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.

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.

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.

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

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

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.