Closed Bug 43847 Opened 25 years ago Closed 24 years ago

[TXT]Textbox size does not match specified width if not using the default font.

Categories

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

x86
Windows 2000
defect

Tracking

()

VERIFIED WORKSFORME
Future

People

(Reporter: steve, Assigned: rods)

References

()

Details

Attachments

(3 files)

From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) BuildID: 2000061311 If you examine the page specified in the included URL, you will notice that the textboxes do not use the default font. The width specified should cause the textbox to size to the width of the specified number of characters in the specified font, but it appears to be sizing to the width of the specified number of characters in the default textbox font. In other browsers, the sizing does appear to occur correctly. Reproducible: Always Steps to Reproduce: 1. Add a textbox control to an HTML form. 2. Change the font using a style attribute, to say, Verdana 8pt. 3. Specify a width of 16 characters. Actual Results: The textbox appears to have been sized to accomodate the width of 16 average width characters in the default textbox font. Expected Results: The textbox should be sized to accomodate the width of 16 average width characters in the specified font.
Rod, I know this sounds crazy but I think this is really a huge rendering bug for html form controls. I reported it as such as early as bug #2357 (way back when :-]), so this bug is probably a dupe. I think that the main point of my bug #2357 report and this bug report, is that when you declare a variable width font like verdana or tahoma, the input [type="text"] width sizes huge and breaks many internet pages where you have forms in tables (ex. Bugzilla forms break). You will not believe how many people consistently post to css help newsgroups complaining about this width sizing behavior. I seems that the NG's consensus is now to avoid using variable width fonts in form controls just because of this nasty behavior for NAV4 and continued in mozilla. It is wrong that a <select>'s width barely changes while a input[type="text"] basically doubles in size whenever declaring a variable width font.
First, does mozilla's behavior match Nav 4.x behavior? Second, does it size reasonably in standard/strict mode?
could use a testcase since the URL is dead. adding qawanted to put on community tsting and qa radar as a bug that needs a testcase and further investigation.
Keywords: qawanted
I have updated the URL for the testcase.
I couldn't load the testcase UL. Something about invalid client? Also, is this a dupe of 2357? without seeing the testcase it's hard to tell...
Confirming. This is not a DOCTYPE issue; even with a strict DOCTYPE Mozilla gets this wrong. Nominating nsbeta3 - if this doesn't get fixed, we'll be using fixed-width fonts in forms until the end of time. Gerv
Severity: minor → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawantednsbeta3
I can't remember the bug #, but I have gone into a long dissertation. The width of the input text and textarea will never match their "size" attr whe using a variable width font: The width is based on the average width of a character and you can use the font metrics average character width or you can do you own calculation. In IE for size=13: String Displays ---------------------------------- 012345678901234 012345678901 (11 chars almost 12) IE size=6: String Displays ---------------------------------- 0123456 123456 (6 chars) abcdefghijk abcdefg (7 chars) ABCDEFGH ABCDEF (6 chars) XXXXXXXX XXXXXX (6 chars) WWWWWWW WWWW (4 chars) Moz always displays many more chars which is closer to what we do in 4.x. I did a little experiement for standard mode (because out hands are tied for NavQuirks mode. So instead of using our calculation for the average char width, I used the average char width as determined by the font metrics. And surprisingly enough it didn't match IE (it was a lot smaller). So I mulitplied the font metric's ave char width by 1.5 and that came very close to IE but not the same. So it all begs the question: What is the formula for calculating the width of a text field with a "size" attr and a variable width font?
Status: NEW → ASSIGNED
Target Milestone: --- → M18
There is also an issue that we don't Nav 4.x exactly and we used to. There is a problem with the Font Metrics, we are now getting different values than we did in M12. changing to future until we can check this all out
Target Milestone: M18 → Future
Marking nsbeta3-
Whiteboard: [nsbeta3-]
Updating QA contact.
QA Contact: ckritzer → bsharma
Summary: Textbox size does not match specified width if not using the default font. → [TXT]Textbox size does not match specified width if not using the default font.
I really have no idea how to correctly size text fields when they have a proportional font. removing future, keeping it a P3
Whiteboard: [nsbeta3-]
Target Milestone: Future → ---
*** Bug 68664 has been marked as a duplicate of this bug. ***
QA Contact Update
QA Contact: bsharma → vladimire
*** Bug 71149 has been marked as a duplicate of this bug. ***
Target Milestone: --- → Future
See http://www.mozillazine.org/talkback.html?article=1906&message=19#19 for a rant about this bug. From bug 25657: > 3) When in Standard mode and the font is a variable width font it is > completely unclear as to what algorithm should be used to calculate it's size. Robert, can you help out with an algorithm here? Or recommend some other expert?
Keywords: mozilla1.0
CCing CSS wizards in case they have anything to say. First, it looks like there are a lot of bugs running around that deal with this issue. Q&A should consolidate them into one (unless there are multiple distinct outstanding issues). Anyway, rods has commentary in bug 25657 that is nice and clear: ------ Additional Comments From rods@netscape.com 2000-11-30 13:14 ------- ... The requirements I obey are as follows: 1) When a page is not in "strict" mode it must size on the Windows platform the same as Nav 4.x on Windows (it does that) 2) When in Standard or Strict mode and the "size" is set, it must size correctly when in a fixed width font (this is not working correctly, there is an extra char being added in) 3) When in Standard mode and the font is a variable width font it is completely unclear as to what algorithm should be used to calculate it's size. ---------------------------------------------------------------------------- AFAICT, 1) and 2) are currently working. People may disagree with the decision to follow Nav4 sizing in Quirks mode, but it doesn't seem clearly unreasonable. Maybe some education needs to happen about that. That leaves issue 3) which AFAIK is still unresolved. Perhaps someone should figure out exactly what IE does and we can clone it if it's reasonable, or choose the closest reasonable algorithm if IE's algorithm is not reasonable. Reverse engineering IE's algorithm should be doable by any motivated person ... Andreas, can you find a volunteer? :-)
Hmm, I'm on linux. Anyone on Windows out there?
I've been trying to resolve the IE algorithm to calculate form widths with non monospaced fonts. After a while, I think it's impossible, so maybe we can create our aproximate algorithm. I think that approaching to IE sizes are better than the current sizes. Now input=text controls with non monospaced fonts are very wide and the form pages looks bad. Do you agree with this approach?
It's fine with me if someone comes up with an algorithm that gets us close to IE's size (at least for text fields and areas)
*** Bug 82727 has been marked as a duplicate of this bug. ***
I will try to give you a method to calculate widths approaching IE5 widths in some days. Give me some time to test all the possible cases.
Hi rods, I've been investigating but now maybe I need some help. IE assigns a constant width for each character on each font type and size. For example: font-family:arial ;font-size:12pt -> Real width for every char = 7 pixels font-family:arial ;font-size:14pt -> Real width for every char = 8 pixels font-family:arial ;font-size:22pt -> Real width for every char = 13 pixels font-family:verdana ;font-size:12pt -> Real width for every char = 8 pixels font-family:verdana ;font-size:14pt -> Real width for every char = 10 pixels font-family:verdana ;font-size:12pt -> Real width for every char = 15 pixels font-family:Times New Roman ;font-size:12pt -> Real width for every char = 6 pixels font-family:Times New Roman ;font-size:14pt -> Real width for every char = 10 pixels font-family:Times New Roman ;font-size:12pt -> Real width for every char = 12 pixels Now We must to find how to calculate this constant widths for each font. I've tried to figure wich letters on each font have this widths, but, Must I count the rouding space pixel on each char or just the width of the printed letter. I really don't know wich Mozilla function returns the real width of a letter and how this function (method) calculate it. I include an image showing you that the IE algorithm is more simple than we thought at the begining. We just must to calculate the constant width for each font type. As you can see, the image is a table. Each row represents a font width 3 font sizes_ 12, 14 and 22pt. the first row is font arial, second font verdana and third font Times. First text on each cell are size=1 second size=3, third size = 6 and the last size = 12. As you can see, there are an overhead on the size=1 (I think it's a bug on IE5) but then, the size increment is constant. I've included on the top of each cell wich letters have the size of the "standard char width", but I'm not sure if I've calculated the character width correctly. What do you think about?
rbs, you know a lot about fonts and character sizes, don't you? Can you help answer the questions(s) from Vincente Salvador?
Sorry for the spam but... Is anybody out there? I need some help to create an algorithm for rods ;-)
I am not sure how to deal with this one. Seeing your screenshot, unpredictable characters are involved for each stylistic combination. The problem seems to be similar to that of finding the horizontal unit of a dialog box (the tmAveCharWidth that is currently used in Mozilla has the bad reputation of being unreliable for accurate placements -- it is sometimes just the witdh of 'x'). If it is possible to get the baseunitX of a dialog box set to the current font, then that value could perhaps be tried to see if it is a good approximation of the average character width to use for text fields here. There are some comments about dialog base units at: http://support.microsoft.com/support/kb/articles/Q125/6/81.ASP http://support.microsoft.com/support/kb/articles/q145/9/94.asp
1. Maybe rods can have some tests, but this is only for Windows Platform. How can we resolve same problem for other UNIX platforms or in machintosh? 2. Can we have a mix like an "standard" char width for some "standard" fonts and the rest been calculated with some algorithms? 3. I cannot develop this Windows Tests to see what baseunitX returns for each of my examples and see if it's an aproximate value. Can anybody with windows developing experience do this tests?
What is needed is a good implementation of nsIFontMetrics::GetAveCharWidth() on each platform, and rods' XP layout code will do the rest. Currently, nsIFontMetrics::GetAveCharWidth() isn't even implemented on other *nix platforms. On GfxWin, it just returns tmAveCharWidth and this isn't really good for the kind of accuracy that you folks want.
Hi rods, Thanks to rbs you know how to implement nsIFontMetrics::GetAveCharWidth () properlly on Windows platform. If Unix are dificult to implement maybe we can use a simple multiply factor to the font size. This multiply factor can be diferent for each font type. Here are some examples on wich I've tested it works properlly. Arial font size * 0.6 Verdana font size * 0.7 Times font size * 0.5 If this works for you, we can test other fonts and determine wich are the factors for other fonts.
Now widths of inputs seems to be more accourate. I've tested it on Build ID 2001082608 Win2000 and it 's similar to IE widths. Has this bug been solved?
Yes, I was able to better approax. and algorthim for sizing and checked in the fix. makring works for me
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Verified Build 2001082008 os:win98,win2000
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: