96414 - [LNX]Form controls should not use sans-serif fonts

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect, P1)

Description

[James Green]

Form textfields are now using sans-serif fonts by default in a new profile on
Linux. They should be fixed width only.

Screenshot coming up. I don't think this bug was present before today's builds.

Comment 1

[James Green]

Attachment: Screenshot showing variable-width font being used throughout

Comment 2

[rods (gone)]

We made a conscience decision to do this. marking won't fix

But I will note your vote for fixed font for form controls on Linux.

Comment 3

[Asko Tontti]

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

Comment 4

[coen]

Another vote for fixed please. (On MS windows)

Can you give me the #bug of this decision

Comment 5

[Warner Young]

Rods, is there a particular reason to do this?  The "Additional Comments" form
in Bugzilla show up as monospace in both NS 4.x and IE 5.x.  In any case, even
if you keep the font as proportional, is it possible to make it the same size
text as the rest of the page?  On the current build, the form text looks to be
one "size" smaller than the regular proportional text on the page.

Comment 6

[rods (gone)]

I am not sure how I missed this, but I thought IE used a sans-serif font for 
textareas. This is going to be a problem for getting the right font, because 
both the text field and area both is the "field" font.

Comment 7

[Warner Young]

IE *does* use proportional font in some of the text areas, but not in the
Additional Comments area.  I don't know how IE know when to use what font, but
I'll take a wild guess that it uses monospace font for multi-line text inputs? 
Anyway, like I said, the other problem is the textarea font is smaller than the
non-textarea font.  Or should that be filed as a separate bug?

Comment 8

[rods (gone)]

My point was that IE uses sans-serif for input text and serif doe textareas. If 
the size is wrong on UNIX that should be filed as a UNIX only bug.

Comment 9

[Warner Young]

I'm actually seeing the wrong size text on Win98.  I have no way of testing
other platforms, so I don't know if it's a Windows-only problem.

Comment 10

[sairuh (rarely reading bugmail)]

i see this on mac 9.1, winnt and linux using 2001.08.22.0x-comm bits.

Comment 11

[rods (gone)]

Warner, what controls have the wrong font size and can you do a small screen 
shot of the control(s) that is/are wrong?

Comment 12

[Warner Young]

Attachment: PNG attachment showing wrong font size.

Comment 13

[Warner Young]

Created attachment.  Rods, if you look at "@netscape" in QA Contact and compare
it to the same string in Assigned To, you can see the QA Contact line is
smaller.   The font size is also wrong in the CC list, and the Additional
Comments box.

Comment 14

[Dave Miller [:justdave]]

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

Comment 15

[Dave Miller [:justdave]]

Repeating my comments from bug 96555:

Textareas have traditionally been monospace, and Bugzilla relies on that.  The
TEXTAREA tag does allow you to specify a style, and sites that want proportional
textareas can use styles to make them proportional.

A proportional font in a textarea will make it very difficult to edit tables of
data, which are often entered in Bugzilla comments.

Comment 16

[Gervase Markham [:gerv]]

I'm not quite sure why this bug is phrased as "serif" vs. "sans-serif" - surely
it's "proportional" vs. "monospace"?

4xp on Linux is monospace in both textfields and textareas. Textfields are an
open question, but having monospaced fonts in textareas is extremely important,
as Dave points out, for applications where people enter tabular data, or e.g.
webmail, where you need a certain number of columns of text per line.

Because these have traditionally been monospace, the onus should be on people
who want proportional to style the textarea appropriately.

Gerv

Comment 17

[Ashley Bischoff (blog at handcoding.com)]

Dave Miller wrote:
> Textareas have traditionally been monospace, and Bugzilla relies on that.  The
> TEXTAREA tag does allow you to specify a style, and sites that want proportional
> textareas can use styles to make them proportional.

Though I have a personal preference for monospace fonts as a default, I'll play
devil's advocate with Dave for a moment. Just as you mention that  sites can use
CSS to specify proportional fonts for TEXTAREA tags, sites can also use CSS to
achieve monospace fonts in their TEXTAREA tags. For instance, it wouldn't be
hard to specify monospace fonts for Bugzilla:

TEXTAREA
{
         font-family: monospace;
}
Another issue is that it seems that IE uses proportional fonts by default -- so
it would make sense for web authors looking for monospace TEXTAREA tags to force
monospace through CSS anyway.

Comment 18

[Gervase Markham [:gerv]]

Yes, either side could style. However, there's a lot of legacy code out there.
While quite a few apps depend on monospace, I doubt very much any depend on it
being proportional. Therefore, we should go for backwards-compatibility and
stick with proportional.

Gerv

Comment 19

[Tim Powell]

Actually, IE4, IE5, and IE5.5 all use a monospaced font for textareas by default
(not for input type=text, though). As does Netscape 4.x. Mozilla should also use
a monospace font in textarea. 

Comment 20

[Dave Miller [:justdave]]

Gerv said:

> Therefore, we should go for backwards-compatibility and stick with proportional.

Did you mean monospaced here or did you change your mind?

Although yes, you can specify a monospaced font just as easily in the style, all
the old browsers use monospace, and lots of sites use pre-CSS HTML.  The whole
idea of HTML 4 was to be backwards compatible with the earlier HTML
recommendations, and by using proportional fonts by default here is violating
the spirit of the W3C recommendations.

Comment 21

[rods (gone)]

Attachment: patch file

Comment 22

[rods (gone)]

Here is what my patch does:

Since IE use a prop system font for input text and a monospace font for 
textareas and the CSS spec only defines a "field" font that can't work for both 
I had to create a new "system" font so to speak that is nonspaced and the size 
is tied into the default fixed font size that is controled by the browser (that 
last part is important) The new font is "field-fixed"

So "field" is a proportional font and its size is tied into the default prop. 
font size.

Other than deciding whether "field-fixed" is a good name, I think this should 
fix everything.

Comment 23

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

I guess I don't see why we need a new system font.  Can't this be done in CSS? 
(I include the CSS strings in nsGfxTextControlFrame2.cpp.  Can't you just use
font-family: monospace and (for inputs) 'font-size: small' there?  Or whatever
it is that your patch does -- I didn't completely follow.)

Comment 24

[Gervase Markham [:gerv]]

(Note: I didn't change my mind - I meant monospaced. My mistake :-)

Gerv

Comment 25

[rods (gone)]

Beyond what font face is used the entire issue as to why I need a new "system" 
font is that the size of the text control's font needs is determined by the size 
of the default font. The default font's size is controlled by the browser.

When you adjust the proportional and fixed font sizes in the Prefs->Font dialog 
you are actually controlling the "default font" (proportional) and "default 
fixed font" sizes.

So if it is defined in CSS then it isn't controled by the Browser's prefs, which 
means it is reducing current functionality AND it also impacts Accessability. 
Because some of those users need to increase the font sizes in the Prefs and the 
form controls need to increase their sizes with them.

Having "system" fonts was the only way to be able to define a font and NOT it's 
size so it could be tied to either the system defined GUI font size or to the 
browser's setting for the font size.

Now, of coarse, I need a new system font because in NavQuirks both input text 
and textareas used the same font. In standard/strict mode the input text uses 
the "system" GUI font face and the size comes from the browser's default font 
for proportional fonts. The problem being solved here, is that I now need a new 
"system" font definition that is a monospace font face and its size is tied to 
the browser's default fixed font.

Comment 26

[Gervase Markham [:gerv]]

rbs is 95% through rewriting a lot of our font handling, so perhaps this issue
may have another solution. CCing him.

Gerv

Comment 27

[rods (gone)]

I am not sure how a rewrite of the font system effects this.

Comment 28

[rbs]

gerv: Wow, "rewrite" is such a big word :-) I would say that I am fixing some
core bugs (yes, hard with ramifications in many areas at once) that were left by
the pionneers :-)

rods wrote: "I need a font definition that is a monospace font face and its size
is tied to the browser's default fixed font."

That's the _exact_ definition of "-moz-fixed", BTW... 

So, a fix for this bug could then just be to change textarea as:

- font: field;
+ font-family: -moz-fixed;

(I tried it and it works)

Currently the Fonts prefs entry for "Monospace" is misleading. (It is not
possible to assign different font sizes to the CSS generic fonts in the current
setup -- bug 74186 -- that's one of the things that my font changes are going to
allow.) When people change the size _labeled_ as "Monospace" on the Fonts
dialog, they are actually changing the size of "-moz-fixed". This is resulting
in a confusion and evey now and then I get cc:ed on some bug reports filed by
those people who care to change the prefs. The current plan is to expose both
"-moz-fixed" (the default "Fixed Width Font") and "Monospace" to allow greater
flexibility and avoid the confusion - bug 61883.

Comment 29

[rods (gone)]

Ok, that is great news. I would rather just use -moz-fixed then and the patch is 
simply a change to the form.css like has been desired and suggested. 

When is the font work going to be checked in 0.9.4?

Comment 30

[rbs]

The target is m0.9.5, hopefully. It is blocked by bug 96609 because it requires 
sync:ing all the zillion flavors of GFX.

Comment 31

[rods (gone)]

Well, maybe for 0.9.4 we should just use as dbaron has suggested monospace and 
small. And then can set it to -moz-fixed for 0.9.5

Also, one other fix in the patch is that I am decreasing the point size of the 
"field" font on Linux by 2 points. Do any of you Linux users think the current 
"field" font in the input text is too big? When monospace/small is used in the 
textarea the input text looks too big.

Note: that we also reduce it by two point sizes on Windows.

Comment 32

[rbs]

You can alreay use -moz-fixed. It has been around since day 1 of Gecko (or
near). Its aim is to emulate the default "Fixed Width Font" a la Nav4.x's Fonts
pref dialog.

Comment 33

[rods (gone)]

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

Comment 34

[rods (gone)]

Yes, I know -moz-fixed has been around for a long time, I just wasn't sure 
whether I could/should use it now or wait.

Comment 35

[rods (gone)]

Attachment: low risk patch

Comment 36

[rbs]

r=rbs

Comment 37

[David Hyatt]

sr=hyatt

Comment 38

[Asa Dotzler [:asa]]

a=asa on behalf of drivers. 

Comment 39

[Katsuhiko Momoi]

CC'ing i18n folks.

Comment 40

[rods (gone)]

fixed

Comment 41

[doctor__j]

I've found that if I add the line
user_pref("layout.forms.use_standard_or_quirks", false);
to pref.js, the bug will appear again.

Will you consider it fixed then?

Comment 42

[Chase Tingley]

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

Comment 43

[tor]

I've built a tree with your checkin, and now I'm seeing a serifed proportional
font for textareas versus a larger sans-serif proportional font for text
entries.

Comment 44

[rods (gone)]

tor, on what platform?

Comment 45

[tor]

Linux (RH 7.1), XFree86 4.0.3, x font path:

/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/75dpi/:unscaled,/usr/X11R6/lib/X11/fonts/100dpi/:unscaled,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/

Comment 46

[rods (gone)]

Moving to 0.9.5

Comment 47

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

It would be good to see this fixed for 0.9.4.

Comment 48

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

Eek.  The patch that was checked in is completely invalid CSS.  "-moz-fixed" is
a value for "font-family", not for "font".  That's probably the problem here...

Comment 49

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

Attachment: fix

Comment 50

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

Attachment: better fix

Comment 51

[rods (gone)]

Gosh, I am just out of it. I should have stayed on sab.

r=rods

Comment 52

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

The second fix is better since it doesn't allow external font styles (such as
large / small font sizes) to leak into textareas.

Comment 53

[Marc Attinasi]

sr=attinasi (for either of dbarons patches, actually)

Comment 54

[chris hofmann]

a=chofmann

Comment 55

[James Green]

With dbaron's 2nd patch applied (not the 1st), I have proportial-width fonts in
all form controls except <textarea>s.

Comment 56

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

That's the intent.  See, e.g., 2001-08-23 11:45 comments.

Comment 57

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

Revised fix checked in, 2001-08-27 13:56 PDT.

Comment 58

[:deanis74]

The first patch from today changed "font" to "font-family":

-  font: -moz-fixed;
+  font-family: -moz-fixed;

The second patch, and what was checked in according to lxr, kept it as "font":

-  font: -moz-fixed;
+  font: medium -moz-fixed;

What happened to "-moz-fixed" applying to "font-family, not "font"?

Comment 59

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

'font' is a shorthand property that sets a bunch of font related properties, and
requires, at a minimum, that the 'font-size' and 'font-family' be specified (or
else the declaration is invalid and thus ignored).  The first change made it so
that all the properties other than 'font-family' weren't reset anymore, whereas
the second made a valid declaration for the 'font' property by specifying the size.

Comment 60

[doctor__j]

I am seeing this bug again on Win32 trunk build 2001083005 !!!
Nasty bug!

Comment 61

[rods (gone)]

input text=text uses sans-serif and textareas use monospace. I have a build from 
last night and it looks fine to me.

Comment 62

[Basil Fritts]

WFM using the same build (2001083005 Win32-trunk). Make sure you're not using
old profile data. In an extreme case, you may need to blow away registry
entries. (Be sure to back it up, first!)

Comment 63

[Andreas Franke (gone)]

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

Comment 64

[doctor__j]

I can still see the problem in some text boxes of the Bugzilla pages (namely,
the QA Contact, Summary, Status Whiteboard, etc.) using Win32 trunk build
2001090400.

Comment 65

[Basil Fritts]

doctor__j:

Just to be clear: what exactly is the behavior you are seeing? Per the
discussion above, you should be seeing a proportional width font in INPUT tags
(eg, status whiteboard, etc.) and a monospaced font in TEXTAREA tags (eg,
Additional comments). Is this not the behavior you are seeing?
See also these comments above:
Additional Comments From [e-mail] 2001-08-23 11:45 
Additional Comments From James Green 2001-08-27 13:25
Additional Comments From David Baron 2001-08-27 13:28

Comment 66

[doctor__j]

What I'm trying to say is that I used to see the input field and password field
displayed in monospaced font just as NS4.x do.  But this time the display style
has shifted toward the IE camp, i.e. proportional font used in displaying input
field and password field.

Unless you add
user_pref("layout.forms.use_standard_or_quirks", true);
to pref.js, I would say this is a 4xp bug.

Please load the testcase below on different browsers for comparison.

If necessary, I'd file another new bug for this issue.  Thanks.

Comment 67

[doctor__j]

Attachment: Testcase

Comment 68

[Peter Lairo]

Shouldn't monospaced fonts only be used where layout positioning is relevant
(e.g., "additional comments), and variable width used where readability
outweighs positioning (e.g., almost everywhere else)?

This would be an "evolution" or "improvement" from NC4 and not a bug.

Comment 69

[Tim Powell]

Marking fixed based on comments above. Textareas (multiple line text boxes) use 
monospaced fonts. All other fields (including input type=text, and 
type=password) use proportional font. This is the expected behavior after 
fixing this bug, even if it is different than Netscape 4.x.

In response to variable-width fonts in single line text fields, Rods said in 
his 2001-08-22 07:20 comment, "We made a conscience decision to do this. 
marking won't fix

But I will note your vote for fixed font for form controls on Linux."

Doctor_J, perhaps an enhancement bug should be filed for using a monospace font 
in all text fields (or reopen the one you logged that got marked as dup). The 
only reason I can see to use fixed-width fonts for input=text is to guarantee 
that you can see all the characters specified by the size attribute. With 
proportional fonts you may or may not be able to see them all (if the fields 
are sized based on less than the widest character). In almost all cases this 
will not be a problem and the improved readability is worth the trade. 
Proportional fonts are also used in text fields in dialogs on windows, so this 
change brings the browser more in line with the OS.

Comment 70

[doctor__j]

Well, I think I'm not going to file another bug coz I am satisfied with a
modified pref.js, namely by adding the line
user_pref("layout.forms.use_standard_or_quirks", true);

Thanks for the comments, tpowell.  I must say that I'm very proud of the work
done by all Moz developers.

Comment 71

[Gervase Markham [:gerv]]

Can someone explain the reasoning behind that pref name?

use_standard_or_quirks = true

So are you using standard? Or are you using quirks? Or both? And what do you get
if you set it to false?

Gerv

Comment 72

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

It means to use the standard mode or quirks mode form control implementations
depending on the layout mode rather than always using the standard mode form
control implementations regardless of the mode (the default, and my strong
preference since forking this much between modes leads to many undiscovered
bugs, as we saw when this change was made).

Comment 73

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

And, FWIW, the fonts used for inputs on GTK should improve a bit once we
implement CSS2 system fonts on the GTK port (bug 33313).