Default font size is one of the more important settings in an Internet browser.
It is suggested that we have a very simple UI to set default font faces and
sizes, in the installer. Here is an excerpt from the discussion:
The sizes and fonts of text in Web pages are
often based on your preferences. Select your
preferred text sizes and fonts, making sure
all sizes remain legible:
| This is "medium" text. 0123456789&ABCD |A|
| This is "small" text. 0123456789&ABCDE | |
| This is "x-small" text. 0123456789&ABC |x|
[_Larger_] [_Smaller_] 16
Serif: [_Times_New_Roman____] (x)
Sans-serif: [_Arial______________] ( )
Note the word "often" in the setup. And larger/smaller buttons accompanied
by a counter showing state - the px value on "medium". All onclick events
update the preview. Larger/smaller buttons decrement the counter by 1px
below 16px, and increment it by 2+px above 16px.
This is an enhancement, marking as such. Other solutions were discussed in the
newsgroups that do not involve the installer, and I've never seen an installer
that sets such trivial preference details. Default font size should be set
based on some relation to the user's preferred system font size.
Further more I believe it's mostly the Unix folk having font size issues and we
don't have an installer for Unix.
I don't think it's mostly Unix folk. The problem is a basic one on the web.
Web "designers" believe that users never change the default font size, so they
write all their pages to *lower* the font size from the default, since they
think the defaults look to big. This causes problems for users for whom the
default isn't too big. If this were part of the UI of a major browser, then
designers would start assuming that users set their font size as they want it
and stop trying to mess with it.
IMO, font size is the MOST important part of the UI of a browser. The most
common complaints I hear about using the web from people my parents age are that
all the fonts are too small, and they can't read anything. Many of these people
don't know how to change the default font size.
I agree very strongly with David. This is not a "trivial preference detail." It is as essential as any
other particular captured in the profile setup. It's the "do you read me/can you read this?"
question, properly prior to any further communication. There are no XP system preferences for
"medium" text size anyway - only for specific OS contexts like window or icon labels. Please
review the relevant threads and reconsider.
Visit your favorite high-traffic site and determine the percentage of the source HTML size
responsible for setting the font size to something lower than the obscure user preference size,
presumedly left at the 12pt default (16px at the Windows default). My investigations turn up
figures between 10 and 30%. Consider the speed (to say nothing of usability) benefits if font-size
UI is rescued from its present obscurity and authors begin to respect the user font-size
adding selmer to the CC: list in case this could be better dealt with within the
Whereas preferences are, in fact, stored in the profile, profile manager does
not manage preferences. The preference manager does that. In any case, the
fundamental decision would be whether to bulk the initial startup with this
added dialog. If this gets added to the installer, it must be controlled with a
config.ini setting so it can be turned off at need.
The profile manager would not be the place to implement this dialog.
It's also not clear to me why Edit|Preferences|Appearance-Fonts is too hard to
discover. Isn't that the standard place to find such a thing with ANY app?
It's perfectly clear to you and me, but not to 90% of users. Therefore, web
"designers" believe that they should design web pages assuming that users never
change the default preferences. Since the default fonts are too large for their
(young) eyes, web "designers" make pages that reduce font size. Some of these
set fixed font sizes. This makes web pages even harder to read for older users
than they would be if they just had the default.
Web pages are about reading text. The size of that text is one of the most
important usability aspects of the browser.
Reassigning to German, we obviously need this looked at from a UE perspective.
The install wizard is *not* the right place for this as it knows nothing about
profiles plus the wizards are platform native and can't show what Mozilla is
going to show.
The Profile Creation code could do this, but it seems mighty odd to special
case this one preference (though I can see your point).
Or we can admit the default font size is wrong and adjust it based on the
screen size or something. Or make an additional preference that sets a minimum
font size, or which says "ignore font size settings", or ...?
I would also not be sure why to single out this preference, I am sure other will
make the case for other things to add to the installer. Why not have a start page
when the browser gets loaded the first time that show the fonty choices more
Keep in mind that:
- the installer is all native and does not have any awareness of how Gecko
- the installer should be kept to a bare minimum to minimize the initial download
- users will likely not have the patience to walk through multiple setting
dialogs before they can finally use the product.
Therefore my vote goes to doing this in an intelligent startup XUL/HTML page.
Frowarding to Don to look at possible implementations...
German's "smart startup page" sounds like a sound approach to me. The point was never
really to get this pref in the installer, but to get it "front and center" someplace in the
Adding myself to cc list.
If we do anything, it will have to be done in consideration of the
Move to M20 target milestone.
Can we agree that installer is the wrong place? I think a preference chrome
loaded in the sidebar on first run would probably work, and we do have bugs
about useful preferences in the sidebar [it'll never happen].
Asa should we move this somewhere else?
I like german's suggestion. I would further suggest that if someone decides to
bring this font choice to "front and center" either in the installer, the
sidebar or a startup page that it would probably be a good idea to disucss this
in the newsgroups and look for some consensus before spending significant
resources on it.
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
Changing obsolete M20+ milestones to closest equivalent, "Future"
-> default owner
Thought this was dead long ago. Let one guy in and everyone will want to be set
in the install.
See comment 8, comment 9, and comment 12.
If someone wants to re-word the summary so it doesn't sound like an Installer
request and reassign to XPapps then feel free to reopen. Since blaker just
reassigned this out of the XPapps group I'm assuming they don't want to do it
I think blake just did a mass-reassign of vishy's bugs to the default owner.
I agree, we should have something like was originally suggested by Erik. I also
suggest on platforms that have font families (Like on X) we should be trying to
look for Microsoft's free ttf fonts. (Yes, I know its Microsoft, but they look
very good) From what I've seen (atleast at 75dpi font (_not_ 72dpi))
monotype-arial of serif, monotype-times new roman as sans-serif, and
monotype-courier new as monotype. With, of course, proportional set as serif @
16, and monospace set as 12, with a minimum font size of 10.... that whole setup
looks _alot_ like msie, and imho looks very good. However, I dont know what msie
uses for cursive and fantasy by default, but they are probably monotype or
microsoft family fonts.
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
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.
Because of this, we're resolving the bug as EXPIRED.
If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.
Query tag for this change: EXPIRED-20100420