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)
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.
Comment 1•25 years ago
|
||
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.
Assignee | ||
Comment 2•25 years ago
|
||
First, does mozilla's behavior match Nav 4.x behavior?
Second, does it size reasonably in standard/strict mode?
Comment 3•25 years ago
|
||
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
Reporter | ||
Updated•25 years ago
|
Reporter | ||
Comment 4•25 years ago
|
||
I have updated the URL for the testcase.
Comment 5•25 years ago
|
||
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...
Comment 6•25 years ago
|
||
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
Comment 7•25 years ago
|
||
Assignee | ||
Comment 8•25 years ago
|
||
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
Assignee | ||
Comment 9•25 years ago
|
||
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
Assignee | ||
Updated•25 years ago
|
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.
Assignee | ||
Comment 12•25 years ago
|
||
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 → ---
Assignee | ||
Comment 13•24 years ago
|
||
*** Bug 68664 has been marked as a duplicate of this bug. ***
![]() |
||
Comment 15•24 years ago
|
||
*** Bug 71149 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•24 years ago
|
Target Milestone: --- → Future
Comment 16•24 years ago
|
||
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? :-)
Comment 18•24 years ago
|
||
Hmm, I'm on linux. Anyone on Windows out there?
Comment 19•24 years ago
|
||
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?
Assignee | ||
Comment 20•24 years ago
|
||
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)
![]() |
||
Comment 21•24 years ago
|
||
*** Bug 82727 has been marked as a duplicate of this bug. ***
Comment 22•24 years ago
|
||
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.
Comment 23•24 years ago
|
||
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?
Comment 24•24 years ago
|
||
Comment 25•24 years ago
|
||
Comment 26•24 years ago
|
||
rbs, you know a lot about fonts and character sizes, don't you?
Can you help answer the questions(s) from Vincente Salvador?
Comment 27•24 years ago
|
||
Sorry for the spam but...
Is anybody out there?
I need some help to create an algorithm for rods ;-)
Comment 28•24 years ago
|
||
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
Comment 29•24 years ago
|
||
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?
Comment 30•24 years ago
|
||
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.
Comment 31•24 years ago
|
||
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.
Comment 32•24 years ago
|
||
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?
Assignee | ||
Comment 33•24 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•