44467 - [TXT][DPD]<INPUT size=XX> larger in Moz than in IE

Status: VERIFIED WORKSFORME

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

Description

[matt]

It still seems that any styles applied to components of a forms. Instead of
applying the style, it messes up the form and makes them too wide or far too
thin like netscape used too

Comment 1

[Stephen Walker]

[e-mail] can you give us some url that is showing this problem or attach 
a testcase possibly?

Comment 2

[matt]

Here are some examples of it happening.
http://www.zorba.co.uk/matt/form3.html
http://www.k10k.net <-- Check the enter mailing list in the corner and the 
missing news item scroller
http://www.designmodule.com.bi Better but still the sizes are messed up

Comment 3

[Pierre Saslawsky]

[e-mail]:
- What is your build id?
- What exactly is the problem on http://www.zorba.co.uk/matt/form3.html? Please 
provide detailed descriptions in the bug reports even if you think that the 
problem is fairly obvious. More information on 
http://www.mozilla.org/quality/bug-writing-guidelines.html

Comment 4

[matt]

On the page http://www.zorba.co.uk/matt/form3.html, the problems that I see are:
1. Borders incorrect - They should be White Solid width 1px on the INPUT & 
SELECt
2. The width of the boxes is totally incorrect they are too wide, which is the 
problem on one of the other sites as well

http://www.rivetnut.com/contact.html is a perfect example of complete size and 
and border mess ups, check in IE and then check in mozilla, dont even think 
about checking in netscape, it cant even position the elements correctly

Comment 5

[Matthias Kerkhoff]

Please have a look at bug #43898, which shows another problem with CSS and 
borders (also, but not only, related to form fields).

Comment 6

[Pierre Saslawsky]

- The declarations for the border are invalid. If you remove the comma (',') 
between "1px" and "solid", it works.
- The boxes are not too wide. The width is specified as [size="35"] and they fit 
35 of the widest letters for that font (try with 'W'). Due to differences in font 
metrics between browsers and platforms, if you need to set the editable fields to 
a precise width, I recommend you to either set the font to a fixed-width font and 
keep [size="35"] (if you need 35 visible characters in that field), or keep the 
font as it is but set the width in CSS with an absolute unit such as pt or px (if 
you need fields of a certain size).

There is a remaining problem with the SELECT elements: they don't show the Up and 
Down arrows. I'll look into it.

Comment 7

[Pierre Saslawsky]

My mistake: Up/Down arrows are displayed in IE; Mozilla has a Down arrow only... 
Anyhow, the arrow disapppears because the 'background' declaration removes the 
'background-image' that shows the arrow. You should either provide your own image 
or change the 'background' declaration to 'background-color'.

All the problems on Zorba are invalid. I'm going to look into RivetNut.

Comment 8

[Pierre Saslawsky]

Same problems on RiveNut as on Zorba: both sites must have been developed by the 
same person because they show the same syntax error in the 'border' declaration.

Still, I'm not closing the bug as Invalid yet. I find the difference in the width 
of editable fields between IE and Moz a little bit troubling because it is fairly 
important. Reassigned to HTML Form Controls to have their opinion.

Changed the summary line from "Style Sheets still not been applied to INPUT & 
SELECT tags" to "<INPUT size=XX> larger in Moz than in IE".

Comment 9

[rods (gone)]

Please review my comments at 2000-01-29 10:35 for Bug 25657, then comment here 
what you think.

Comment 10

[Pierre Saslawsky]

I don't think the '%' was the best choice to determine the field width. On the 
testcase above (http://www.zorba.co.uk/matt/form3.html), it makes the text fields 
in Mozilla really big compared to Nav4 and IE (1.65 times bigger).

A better choice would have been any numerical character '0'-'9'. They have the 
advantage of all having the same width in any font, including proportional fonts. 
It would allow to have fixed-width numerical fields that perfectly match the 
numbers they are supposed to contain. Also, in most fonts, numerical characters 
are a bit larger than alphabetical characters, which means that text fields will 
usually be wide enough but not excessively wide as with the '%' character.

Comment 11

[rods (gone)]

I am not sure where Eric came up with the '%' char. The algorithm is: 
If size=x, then take a string of x 'W' and x 'w', find it's length and divide by 
2. That is how Nav and Mozilla/Quirks sizes the text.

Comment 12

[Pierre Saslawsky]

I'm reopening with the '4xp' keywords because the field widths are really much 
larger in Moz than in IE or Nav.

It looks like IE uses characters such as a,b,c,d or e (which all have the same 
width in most proportional fonts) to calculate the field width. These characters 
are much smaller than the average of 'W' and 'w'.

In Nav4x, the font is always a fixed width font (Courier on all platforms, I 
think). If you compare the string "WwWwWw" in Courier and the same string, using 
the same font size, in any one of the most common proportional fonts (Times, 
Arial, Geneva, Helvetica, New York, Palatino), you can see that the proportional 
font results in a much larger field.

By the way, I don't understand why Nav uses an average of 'W's and 'w's: with a 
fixed-width font, any character would have been just fine.

I suggest we use a digit instead of the current algorithm. As a secondary 
solution, we can also use the character 'a' like IE.

Comment 13

[rods (gone)]

We used to size the same as Nav (when in NavQuirks) pixel for pixel in monospace 
and in sans-serif for each font size. The round off error Peter L. fixed in the 
font metrics did change the measured width of a couple of the sizes.

Yes, there has been a somewhat recent regression in the sizing of input 
type=text for the san-serif font.

We use WwWw because that is what Nav does, why? Your guess is as good as mine. I 
don't see any legitimate reason for changing the algorithm to use anything 
else when in NavQuirks mode. If someone would like to suggest a better way to 
size the textfields when in Standard/Strict mode I am all ears.

The table lists the horz sizing in pixels for each font size for sans-serif


Font   
Size  Gecko   Nav
1      173    152
2      237    173
3      281    237
4      323    281
5      431    366
6      581    474
7      862    732

This used to produce exactly the same sizes, now it looks like we are off an 
entire size our size=1 is the same as Nav's size=2. I still have a 
spreadsheet with all my observations and the comparisons, so I know we 
did match at one point. The spreadsheet is dated 10/15/99.

Pierre, is there anything special or different going on with the font code? 
Peter and I spent a lot time working through these issues, and I know he spent a 
LOT of time early on getting the fonts to match up correctly.

At this point, I don't think this is actually a form control problem, it appears 
to be a regression in some font code somwhere.

Comment 14

[rods (gone)]

Attachment: Testcase for measuring sizing differences for input text

Comment 15

[rods (gone)]

It measured correctly with M11 (Nov 16, 1999), M12 for some reason doesn't use 
the correct font. M13 and M14 are wrong.

Comment 16

[Pierre Saslawsky]

CCd Erik because it is a text size issue.

Based on your comments from the 12th, I was afraid  it could be a regression due 
to the font size code we did with Erik but that's not the case: it wasn't checked 
in for M13.

Comment 17

[rods (gone)]

I will have to file a new bug that this bug will depend on, the code here is 
fine, it just isn't getting the correct font metric information for the 
different font sizes.

Comment 18

[Kevin McCluskey (gone)]

Marking nsbeta3-

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration

Comment 19

[Daniel Veditz [:dveditz]]

Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so 
the queries don't get all screwed up.

Comment 20

[Jens-Uwe]

I think the following page has a similar problem:
http://idealo.bbtt.de/idealo/anmelden.php3
the relevant source code is the following
<td align="left"><input type="Text" maxlengh="100" name="vorname" size="18"
value=""></td>
it seems that the size="18" is completly ignored. I am using the 2000082121
build for linux. Another strange behavior is, that the length of the input field
is increased after the first letter is typed in, but it is still not the 18
chars long.

Comment 21

[Jens-Uwe]

just in case someone cares:
I could not reproduce the problem anymore on the 2 problematic pages I know (the
idealo one mentioned above and comdirect.de) with the 20000903-build :-)))

Comment 22

[rods (gone)]

I have been doing a lot of work with form control fonts and their sizing, 
because, of coarse, the size depends on the font metrics.

Form controls, especially the text field/area, should now size very close to IE 
in Standard/Strict mode (with today's build). So you sould check those site with 
today's build.

Comment 23

[bsharma]

Updating QA contact.

Comment 24

[rods (gone)]

Apparently at the moment we aren't inheriting the font size

Comment 25

[Vicente Salvador]

Hi rods,

Your're right. In strict mode size are similar to IE and more accurate to real 
size, but, Why this sizing algorithm are not functional on non strict mode? 

Comment 26

[rods (gone)]

When it is non-strict we size the same as Nav 4.x

Comment 27

[Vicente Salvador]

Yeah! I know it. But what we should maintain the not proper sizing mechanism of 
NS 4.X. I thin we can improve some "bugs & not proper things" on NS. This new 
generation browser should allow us to change our mind. Mozilla & NS6 are 
radical diferent from NS 4.X (full CSS support, XML DOM, Java 2, HTML 4). With 
all this new functions maintaining NS 4.X compatibility should not be our goal.

Comment 28

[Boris Zbarsky [:bzbarsky]]

Isn't this a duplicate of bug 43847?

Comment 29

[rods (gone)]

If this bug is talking inheriting font info from the font tag, then no it isn't 
a dup, but if not then it is.

Comment 30

[rods (gone)]

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

Comment 31

[Vladimir Ermakov]

QA Contact Update

Comment 32

[Boris Zbarsky [:bzbarsky]]

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

Comment 33

[Boris Zbarsky [:bzbarsky]]

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

Comment 34

[Vicente Salvador]

I've checked the Build ID 20001082608 and now input sizes seems to work fine and
similar to IE. Can anybody check this and mark this bug as WFM?

Anybody know  how this has been solved?

Comment 35

[rods (gone)]

Yes, I turned on standard sizing for input type=text and made a fix to the 
algorthim so we now size very close if not exactly the same as IE.

Comment 36

[Vladimir Ermakov]

verifying build 2001-08-27-03-trunk windows 98