Closed
Bug 262191
Opened 20 years ago
Closed 17 years ago
[OS X] Default font for form controls is too large
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.9alpha8
People
(Reporter: uriber, Assigned: jaas)
References
Details
Attachments
(7 files, 3 obsolete files)
(deleted),
image/png
|
Details | |
(deleted),
patch
|
stuart.morgan+bugzilla
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
(deleted),
image/png
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
patch
|
roc
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
(deleted),
text/html
|
Details | |
(deleted),
patch
|
vlad
:
review+
vlad
:
superreview+
|
Details | Diff | Splinter Review |
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:
Reporter | ||
Updated•20 years ago
|
Summary: [OS X] Default font in form controls (text input, textarea, and select) is too large → [OS X] Default font for form controls is too large
Comment 1•20 years ago
|
||
> 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...
Assignee: nobody → sfraser
Component: Layout: Form Controls → GFX: Mac
QA Contact: core.layout.form-controls
Reporter | ||
Comment 2•20 years ago
|
||
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•20 years ago
|
||
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.
*** This bug has been marked as a duplicate of 198646 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
*** Bug 198646 has been marked as a duplicate of this bug. ***
Reporter | ||
Updated•19 years ago
|
Component: GFX: Mac → Layout: Form Controls
Comment 7•19 years ago
|
||
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.
Attachment #192397 -
Flags: review?(sfraser_bugs) → review-
Comment 8•19 years ago
|
||
(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•19 years ago
|
||
Also, on most platforms, the font size of system fonts depends on various system
preferences. That we obey those is important for accessibility.
Reporter | ||
Comment 10•19 years ago
|
||
(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•19 years ago
|
||
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•19 years ago
|
||
i think camino uses a different form css to adjust the fonts. we don't change
any code in gfx to achieve that, iirc.
Reporter | ||
Comment 13•19 years ago
|
||
(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.
Reporter | ||
Comment 14•19 years ago
|
||
(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•19 years ago
|
||
(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•19 years ago
|
||
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
Reporter | ||
Comment 17•19 years ago
|
||
Mac-specific patch, only affecting <input>s and <select>s (but not
<textarea>s), as per comments above.
Attachment #192397 -
Attachment is obsolete: true
Attachment #192599 -
Flags: superreview?(dbaron)
Attachment #192599 -
Flags: review?(dbaron)
Comment 18•19 years ago
|
||
Comment on attachment 192599 [details] [diff] [review]
Mac-specific patch
hm, this also affects buttons.
Reporter | ||
Comment 19•19 years ago
|
||
(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•19 years ago
|
||
(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).
Reporter | ||
Comment 21•19 years ago
|
||
(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.
Reporter | ||
Comment 22•19 years ago
|
||
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.
Reporter | ||
Comment 23•19 years ago
|
||
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).
Attachment #192685 -
Flags: superreview?
Comment 24•19 years ago
|
||
I prefer attachment 192685 [details] [diff] [review].
Reporter | ||
Updated•19 years ago
|
Attachment #192599 -
Flags: superreview?(dbaron)
Attachment #192599 -
Flags: review?(dbaron)
Reporter | ||
Updated•19 years ago
|
Attachment #192685 -
Flags: review?(sfraser_bugs)
Reporter | ||
Updated•19 years ago
|
Component: Layout: Form Controls → GFX: Mac
Reporter | ||
Updated•19 years ago
|
Attachment #192685 -
Flags: superreview?
Comment 25•18 years ago
|
||
This bug makes many <select>s and some <button>s ugly.
Blocks: 381638
Flags: blocking1.9?
(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.)
Component: GFX: Mac → Widget: Cocoa
QA Contact: cocoa
Comment 27•18 years ago
|
||
I think I like Firefox's use of a monospace font for <textarea>. Are you proposing using a proportional font instead, like Safari does?
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.
Attachment #192685 -
Flags: review?(sfraser_bugs)
Assignee | ||
Comment 29•18 years ago
|
||
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.
Attachment #192599 -
Attachment is obsolete: true
Attachment #192685 -
Attachment is obsolete: true
Attachment #266487 -
Flags: review?(stuart.morgan)
Comment 30•18 years ago
|
||
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?
Attachment #266487 -
Flags: review?(stuart.morgan) → review+
Comment 31•18 years ago
|
||
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
Attachment #266487 -
Flags: superreview?(roc)
Attachment #266487 -
Flags: superreview?(roc) → superreview+
Assignee | ||
Comment 32•18 years ago
|
||
landed "combobox fix v1.0" on trunk
Comment 33•18 years ago
|
||
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•18 years ago
|
||
(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•18 years ago
|
||
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.
Assignee | ||
Comment 36•18 years ago
|
||
Attachment #267614 -
Flags: review?(roc)
Attachment #267614 -
Flags: superreview+
Attachment #267614 -
Flags: review?(roc)
Attachment #267614 -
Flags: review+
Assignee | ||
Comment 37•18 years ago
|
||
"button fix v1.0" landed on trunk
I think all we really need to do now is the text area font.
Comment 38•18 years ago
|
||
Josh, we also need to get this for bug 375563, vanilla <input type="submit">
"button fix v1.0" seems not to have fixed the button in <input type="file">
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.
Assignee | ||
Comment 42•17 years ago
|
||
This fixes them. They are really the only things in the tree using that CSS font value and I tested pretty thoroughly.
Attachment #276236 -
Flags: superreview?(vladimir)
Attachment #276236 -
Flags: superreview?(vladimir)
Attachment #276236 -
Flags: superreview+
Attachment #276236 -
Flags: review+
Assignee | ||
Comment 43•17 years ago
|
||
Landed on trunk, closing out this bug. Please file new more specific bugs for any remaining issues.
Status: NEW → RESOLVED
Closed: 20 years ago → 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•