262191 - [OS X] Default font for form controls is too large

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Uri Bernstein]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10

The default font used in form controls (text input, textarea, and select) is
larger than the font used by other OS X browsers (including Camino), and also
larger than the font used on Windows.
In addition to the non-standard look, this causes certain page layouts (which
make assumptions about the default font) to break, causing Firefox to look
buggy. For an example, see bug #261346.

Details:
The default font for input elements is specified in forms.css as "-moz-field".
This translates, eventually, to a ::GetThemeFont() call with a
kThemeApplicationFont parameter. This call apparently returns 10pt (or 13px)
Lucida Grande, which is what we display.
Camino (and presumably "Cocoa builds" of Seamonkey/Firefox, if such things
exist) override this in the platform-forms.css, specifying "font-size: 11px" for
input, textarea, and select elements. This results in a smaller, more standard
font size fo these controls.

Suggestion:
Make a platform-forms.css for non-Cocoa OS X builds, and specify the font size
for these elements as for Camino.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Boris Zbarsky [:bzbarsky]]

> This call apparently returns 10pt (or 13px) Lucida Grande, which is what we
> display.

Is this not the right font for textfields? If so, we should fix GetThemeFont,
no?  Or fix nsDeviceContextMac::GetSystemFont to map the "field" system font to
something more appropriate?

Fixing this in CSS is all well and good, but it's better to have the system font
code doing the right thing...

Comment 2

[Uri Bernstein]

The 13px font is the "right" font for textfields - i.e. it is the font used on
system dialogs etc. So I don't think there's a problem with the system font code.

However, both Safari and Camino (which are supposed to be the most "Mac native"
browsers out there), as well as IE5/Mac, opted for a smaller font in HTML
controls (possibly in order to preserve the look (and layout) of web pages
designed primarily for Windows).

It would be interesting to have comments on this both from Mike Pinkerton (who,
I assume, made the 11px decision for Camino), and Kevin Gerich (who apparently
likes the current, larger, font - see http://kmgerich.com/archive/000072.html).

General disclaimer - I'm not an OS X expert of any kind, and not even a
full-time Mac user. Everything I wrote above comes from observations I made as a
user (and a bit of digging into Mozilla code), which were prompted by the
discussion on bug 261346.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Ah, ok.  Yeah, as long as the system font code is doing the right thing, I don't
really see a problem with changing the default font-size for compat...

We probably want to do this in forms.css, though, since this would be an issue
in any case when system fonts are not the expected 11px size.

Comment 4

[Frankie]

*** This bug has been marked as a duplicate of 198646 ***

Comment 5

[Frankie]

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

Comment 6

[Uri Bernstein]

Attachment: patch

Per comment #3.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 192397 [details] [diff] [review]
patch

No, you can't do this across platforms.  Furthermore, the first and last
changes are fixing places that use system fonts:  if those are wrong, then the
Mac Gfx code that gets the system fonts should be fixed.  The middle one is
fixing one that depends on the user's default font size.  I think it's that way
because we decided we *want* it to depend on the user's default font size.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(And even after reading bz's comment, I still think it's wrong.  If our controls
are the same size as WinIE's on Windows, why would we need to fix them at a
smaller size cross-platform?  Or are they not?)

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Also, on most platforms, the font size of system fonts depends on various system
preferences.  That we obey those is important for accessibility.

Comment 10

[Uri Bernstein]

(In reply to comment #7)
> (From update of attachment 192397 [details] [diff] [review] [edit])
> No, you can't do this across platforms.  

I was following what I understood from bz's comment. I'll happily make this
mac-specific, if someone helps me out with what #if I should use (so that it
will affect Mac firefox/SeaMonkey, but not Camino).

>Furthermore, the first and last
> changes are fixing places that use system fonts:  if those are wrong, then the
> Mac Gfx code that gets the system fonts should be fixed.  

No, as noted in comment #12, the Mac GFX code is fine. It returns what really is
the system font. Except, other browsers on Mac (Safari, Camino) *don't* use the
system font (size) for form controls - because it's too large. The point was
that we should do the same. You might disagree, but in that case the bug should
be WONTFIXed.

> The middle one is
> fixing one that depends on the user's default font size.  I think it's that way
> because we decided we *want* it to depend on the user's default font size.
> 

Fine. Textareas are much less of a problem anyway, so I have no problem with
dropping that one (note however, that Camino does do this for textareas).

Re comment #8: I don't have access to a Windows machine, so I can't answer that.

Re comment #9: I'm not sure if what you're arguing is that we shouldn't do it
cross-platform (which I have no problem with), or that we shouldn't do it all.
If it's the former, I'll create a mac-specific patch (if I get some help or
figure out how to do it) for inputs and selects only. If it's the latter, well,
I disagree, but it's your decision so the bug should be WONTFIXed.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Does the Mac Widget code always return the "slightly too large" font at exactly
the same size?  Or does it vary based on system preferences?  If so, doing this
at all, even just for Mac, would be an accessibility problem, IMO.  (If not,
then the Mac platform sucks for accessibility for users with poor vision, but
that wouldn't surprise me.)

Comment 12

[Mike Pinkerton (not reading bugmail)]

i think camino uses a different form css to adjust the fonts. we don't change
any code in gfx to achieve that, iirc.

Comment 13

[Uri Bernstein]

(In reply to comment #12)
> i think camino uses a different form css to adjust the fonts. we don't change
> any code in gfx to achieve that, iirc.

See comment #0 (which confirms what you're saying). This used to be in a
platform-specific platform-forms.css, and was later moved (inside #ifs) into the
main forms.css. GFX code was not touched, as far as I could tell.

Can you help me answer dbaron's question from comment #11? I haven't found any
system preferences to change the system font - but I might have just missed it.

Comment 14

[Uri Bernstein]

(In reply to comment #11)
>... doing this
> at all, even just for Mac, would be an accessibility problem, IMO.

I'm not sure I understand the accesability argument here. People who need larger
fonts are likely to need them for everything on the page, not just form
controls. Therefore, they're likely to use cmd-+ (or an extension which does the
equivalent permanently). If the form controls start as being larger-than normal
(because they use a system setting), then increasing the overall font size on
the page will make them too big. What am I missing?

Comment 15

[philippe (part-time)]

(In reply to comment #13)
>
> Can you help me answer dbaron's question from comment #11? I haven't found any
> system preferences to change the system font - but I might have just missed it.

On a default install of OS X (10.3.9), you can't modify the font-sizes in the OS
UI (sucks, yes). One need to install TinkerTool, or maybe some other utility, to
do that.

(personally, I find the default font-sizes for widgets in Camino and esp. Safari
too small to read comfortably).

Comment 16

[philippe (part-time)]

Attachment: screenshot, 3 OS X browsers

Side by side, from left to right: Firefox (latest nightly), IE 5 Mac, Safari
1.3.
All 3 browsers at their default font size.

The test form: http://dev.l-c-n.com/forms/forms3.php

OS X 10.3.9

Comment 17

[Uri Bernstein]

Attachment: Mac-specific patch

Mac-specific patch, only affecting <input>s and <select>s (but not
<textarea>s), as per comments above.

Comment 18

[Asaf Romano (gone)]

Comment on attachment 192599 [details] [diff] [review]
Mac-specific patch

hm, this also affects buttons.

Comment 19

[Uri Bernstein]

(In reply to comment #18)
> (From update of attachment 192599 [details] [diff] [review] [edit])
> hm, this also affects buttons.
> 

No, it doesn't, because of:

button, 
input[type="reset"],
input[type="button"],
input[type="submit"] { 
...

  font: -moz-button;
...
}

Comment 20

[philippe (part-time)]

(In reply to comment #17)
> Created an attachment (id=192599) [edit]
> Mac-specific patch
> 
> Mac-specific patch, only affecting <input>s and <select>s (but not
> <textarea>s), as per comments above.

There is one problem with this patch, from an accessibility point of view.
If/when the user changes his/her default font-size (in the preferences > content
tab) to something bigger (because they need bigger fonts anyway), the widgets do
not resize accordingly. Apply the patch and change your prefs to something like
24px, and access the form I linked to above in comment #16. The select element
remains a 11px, which for a user with poor eyesight would be unreadable.
(and the 24px font-size is what my 75 years old neigbour uses on his iMac with
Firefox)

Note that Safari, Camino and IE Mac all suffer from the same problem. I haven't
tested Opera 8.

Keyword based font-sizing would be better, imho. 'small' gives something close
to the current display for select and input. 'x-small' gets you something closer
(slightly smaller, 10px instead of 11px) to the current Safari/Camino behaviour.
This for the default font-size set in the prefs (which is 16px).

Comment 21

[Uri Bernstein]

(In reply to comment #20)
> There is one problem with this patch, from an accessibility point of view.
> If/when the user changes his/her default font-size (in the preferences > content
> tab) to something bigger (because they need bigger fonts anyway), the widgets do
> not resize accordingly. 

This has nothing to do with the patch. The same thing is true without it. The
font size of the input and select elements is not affected by the default font
as selected by the preferences.

In any case, setting the default font size in the preferences is a poor solution
for accessability, as many (probably most) web pages specify a font size for the
pager, and thus override the user's default font. A good solution would be to
allow the user to permanently apply the "command-+" effect. This effect all
pages, and also form controls, with or without the patch.

Comment 22

[Uri Bernstein]

Ironically, in dialog boxes, which are the one place where accessability
arguments do apply (because the user has no control on text size), we are using
the 11px (small) font. This is because the fonts for dialog is specified as
"message-box" (in global.css), and there is no overriding setting for input
elements (this is apparently true both for Pinstripe and for the SeaMonkey themes).

This is the exact opposite of Safari, which, logically, uses the system font for
controls on dialogs, but a smaller font (by default) for  HTML controls on web
pages.

Comment 23

[Uri Bernstein]

Attachment: Alternative patch

OK, perhaps I wasn't entirely right when I said the Mac GFX code was fine.

This patch fixes the problem by mapping eSystemFont_List and eSystemFont_Field
to kThemeSmallSystemFont, which according to the Apple HIG, should be used
(among other things) "for small controls".

I'm not depricating the previous patch because I'm not sure which is more
correct. I'll let dbaron (and the others) decide which approach to take (if
any).

Comment 24

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I prefer attachment 192685 [details] [diff] [review].

Comment 25

[Jesse Ruderman]

This bug makes many <select>s and some <button>s ugly.

Comment 26

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #2)
> The 13px font is the "right" font for textfields - i.e. it is the font used on
> system dialogs etc. So I don't think there's a problem with the system font 
> code.

Note that Safari uses the small system font for <textarea> and <input type="text">, too (as the latter are rendered as the small size NSTextField).  I'm not familiar enough with the code in question to tell if Uri's patch above does that.

(AFAICT, we should be using the small system font in all cases for HTML form controls, including buttons, since the HTML controls should all be defaulting to the "small" size widgets, at least if we want to match other Mac browsers and not regress Camino, both of which I think we want to do.)

Comment 27

[Jesse Ruderman]

I think I like Firefox's use of a monospace font for <textarea>.  Are you proposing using a proportional font instead, like Safari does?

Comment 28

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I was just proposing the size, which is the main breaking/consistency factor wrt site layouts. I suppose in theory we should, but I happen to like it, too, and, unlike buttons or lists in the OS/apps (which can normally only be sans-serif), text entry can use any sort of font.

Comment 29

[Josh Aas]

Attachment: combobox fix v1.0

I think we'll have to tackle the general issue of font size on Mac OS X piece by piece. This fixes combobox buttons and their associated menus.

Comment 30

[Stuart Morgan]

Comment on attachment 266487 [details] [diff] [review]
combobox fix v1.0

The text looks one pixel too low in some <selects> and fine in others (all on this page). I assume that's just a general font drawing issue?

Comment 31

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: Minefield vs. Safari rendering of UI controls

Minefield (2007/05/31) on the left, Safari on the right.

 - illustrates the font size differences, as well as associated padding differences
 - there also seems to be a difference in the <textbox> rendering, though that might be CSS interpretation differences for bugzilla

Comment 32

[Josh Aas]

landed "combobox fix v1.0" on trunk

Comment 33

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: Minefield vs. Safari rendering of UI controls (after patch)

Minefield (left) vs. Safari (right)

Looks nice! The only other difference is line spacing, but I can't tell if that's a CSS rendering difference on Bugzilla or not.

Comment 34

[philippe (part-time)]

(In reply to comment #33)
 
> Looks nice! The only other difference is line spacing, but I can't tell if
> that's a CSS rendering difference on Bugzilla or not.

Safari/Webkit has a 2~3px margin on form controls by default (from in the UA stylesheets). That explains the differences in line spacing.

Comment 35

[Mike Beltzner [:beltzner, not reading bugmail]]

I wonder if that's something we want to emulate; I'm finding that form elements are looking a litle bit more cramped with the cocoa widgets.

Comment 36

[Josh Aas]

Attachment: button fix v1.0

Comment 37

[Josh Aas]

"button fix v1.0" landed on trunk

I think all we really need to do now is the text area font.

Comment 38

[Asa Dotzler [:asa]]

Josh, we also need to get this for bug 375563, vanilla <input type="submit">

Comment 40

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

"button fix v1.0" seems not to have fixed the button in <input type="file">

Comment 41

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: input file testcase (button text, field text still too large)

Presumably the text field size will be fixed when we fix text fields, but since fixing buttons did not fix the <input type="file">'s button (as seen here), maybe not.

Comment 42

[Josh Aas]

Attachment: fix submit and file, v1.0

This fixes them. They are really the only things in the tree using that CSS font value and I tested pretty thoroughly.

Comment 43

[Josh Aas]

Landed on trunk, closing out this bug. Please file new more specific bugs for any remaining issues.