Closed
Bug 25657
Opened 25 years ago
Closed 23 years ago
[FIX]When does 18 = 29? When you use the SIZE attritbute in a text type input field.
Categories
(Core :: Layout: Form Controls, defect, P3)
Tracking
()
VERIFIED
FIXED
People
(Reporter: edmanet, Assigned: rods)
References
()
Details
Attachments
(3 files, 5 obsolete files)
This drives me nuts.
I use this code:
<input type='text' name='whatever' size='18'>
When I load it up in Netscape 4.x, I can get an input field that is 29
characters wide. What's up with this? This is one of the only reasons that I
can't make truly browser independent web sites. Of course the work around is
to determine the browser and adjust the control size (cut them in half). Why
do you wanna make extra work for me? Please... please...
Assignee | ||
Comment 2•25 years ago
|
||
Assignee | ||
Comment 3•25 years ago
|
||
Attached is a simple example of where ths size is set to 18.
This example shows 18 chars in Nav 4.x, 18.5 char in Mozilla (in NavQuirks
mode) but the form control is 153x24 pixels for Nav 4.x and Mozilla. In IE 4.0
it shows 19 chars and is 139x22 pixels.
If you are setting a different font for the text field, the sizing does get off
because of the simplistic algorithm that was used plus a rounding error in the
font size calculation.
We have corrected the rounding error for the font size calc, so Mozilla in
NavQuirks mode will not always match 4.x. Mozilla in standard mode should always
size to the correct amount of chars. Once IE completely implements CSS maybe
their text controls will always size to the "size" attribute.
I am marking this bug as invalid because there really isn't a problem to be
corrected here, because Mozilla in "Standard" mode will size to the correct
number of chars (if not, then that is a bug)
If you a very specific issue that doesn't appear to be covered by this example
please enter it and some sample HTML.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
Comment 4•25 years ago
|
||
Marking VERIFIED INVALID on:
- Linux6 2000-03-01-13 Commercial build
- MacOS9 2000-03-01-13 Commercial build
- Win98 2000-03-01-16 Commercial build
Status: RESOLVED → VERIFIED
Comment 7•24 years ago
|
||
From bug 7543:
- Stanton McCandlish asks essentially "please default to monospace". Though not
stated, I'm guessing this means in quirks mode.
I just tested this and we are displaying monospace by default <invalid>
- Antti Näyhä included a table of the number of characters actually displayed
versus the number requested for SIZE=14, various fonts, standards mode.
The attachment uses arbitrary characters (specifically 0-9) to determine how
many will fit if width is set to 14. The benchmark character is %. I just
tested in today's build. All five examples fit between 13.5 and 14.5 %
characters, which I think is very close to what is requested.
Comment 10•24 years ago
|
||
Comment 11•24 years ago
|
||
I don't think this bug is invalid - I don't really know what is NavQuirks and
Standart mode, but in Netscape 4 the attachment 14986 [details] the INPUTs have always 6
chars length, but in Mozilla only the second one matches, the others are
absolutely stupid.
Assignee | ||
Comment 12•24 years ago
|
||
NavQuirks mode is non-strict documents, Standard mode is strict documents. In
navQuirks we try very hard to behave like nav 4.x even if it breaks the
standard (HTML 4.0 Standard)
For the first two text fields we size pixel for pixel on the outer edge. As far
as these two displaying more of the text string it is the difference in the way
native controls are displayed versus the way we display them. Native control use
a three pixel border, but it visually looks like two, then they use a one pixel
padding, and then they do not display any of the next char even thought some of
it would fit.
In NavQuirks mode we use a two pixel border and no padding. I could change the
control to use a two pixel padding, but some of the next char would be painted.
Adjustments could be made with padding, but apparently that doesn't work so I
will have to file a bug.
Comment 13•24 years ago
|
||
*** Bug 53054 has been marked as a duplicate of this bug. ***
Comment 14•24 years ago
|
||
*** Bug 58338 has been marked as a duplicate of this bug. ***
Comment 15•24 years ago
|
||
Comment 16•24 years ago
|
||
Please see attach 19864 - this bug is NOT invalid, I think.
Assignee | ||
Comment 17•24 years ago
|
||
Don't compare it to IE, compare it to Nav 4.x and you will see that they measure
the same width and height in pixels.
Our goal was to match Nav 4.x, not IE.
Comment 18•24 years ago
|
||
Hey, this is untrue !
I opened the attach 14986 with NN4 (linux) and all INPUTs have the size 6. With
IE, they have the size 6 or 6.5 (see attach 19864), but mozilla has 10 !!!
I believe the main goal with mozilla was to be standard-compliant, the HTML 4.0
specs says:
size = cdata
This attribute tells the user agent the initial width of the control. The width
is given in pixels, except for control types "text" and "password" when it is
the (integer) number of characters.
IS really 6 equal to 10 and 18 equal to 29 ?
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
Assignee | ||
Comment 19•24 years ago
|
||
Let me be a little more clear, the intention was for them to size exactly the
same on Netscape 4.x for Windows. Most all the content in the world is developed
for IE on Windows and Nav 4.x on Windows. Many sites construct their HTML just
so, so the pages lay out perfectly on Windows, then it lays out however on Linux
and Mac.
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.
I will leave this open to fix the fixed width font problem in Standard mode,
which is the only bug I can find.
Status: REOPENED → ASSIGNED
Assignee | ||
Comment 20•24 years ago
|
||
Assignee | ||
Comment 21•24 years ago
|
||
here is the fix for the monospace off by 1 sizing issue:
Index: nsGfxTextControlFrame2.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/html/forms/src/nsGfxTextControlFrame2.cpp,v
retrieving revision 1.108
diff -u -r1.108 nsGfxTextControlFrame2.cpp
--- nsGfxTextControlFrame2.cpp 2000/11/17 00:25:30 1.108
+++ nsGfxTextControlFrame2.cpp 2000/11/30 21:23:09
@@ -1387,9 +1387,9 @@
if (NS_CONTENT_ATTR_HAS_VALUE == colStatus) { // col attr will provide width
PRInt32 col = ((colAttr.GetUnit() == eHTMLUnit_Pixel) ? colAttr.GetPixelVal
ue() : colAttr.GetIntValue());
col = (col <= 0) ? 1 : col; // XXX why a default of 1 char, why hide it
- aDesiredSize.width = (col+1) * charWidth;
+ aDesiredSize.width = col * charWidth;
} else {
- aDesiredSize.width = (aSpec.mColDefaultSize+1) * charWidth;
+ aDesiredSize.width = aSpec.mColDefaultSize * charWidth;
}
aRowHeight = aDesiredSize.height;
Summary: When does 18 = 29? When you use the SIZE attritbute in a text type input field. → [FIX]When does 18 = 29? When you use the SIZE attritbute in a text type input field.
Comment 22•24 years ago
|
||
rods patch looks good.
r=kmcclusk@netscape.com
Comment 23•24 years ago
|
||
sr=waterson
Assignee | ||
Comment 24•24 years ago
|
||
fixed the one char too big problem when in standard mode.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Comment 26•24 years ago
|
||
I really think this bug should be reopened. Your solution to violate standarts
just because of already-dead Netscape 4.0 on Windows seems completely mad to
me. Why don't mozilla team implement document.all then ? So many websites are
using document.all, it would be very helpful (I don't know _any_ site optimized
for "Netscape 4.0 Windows edition").
Correctly written web page is rendered wrong with NN 4.0 - ok, it's a bug. But
it should be fixed, not supported !
Comment 28•23 years ago
|
||
I agree with the above criticism. The Windows platform snobbery is not even apropos for quirks mode,
when the "quirk" in question is clearly a bug, not a feature of any kind. It's even one that's been avoided and
fixed in every other browser/OS combo I'm aware of. IT BREAKS THE HTML SPEC'S
FUNCTIONALITY. This bug desperately needs to be reopened and *really* fixed.
"This is one of the only reasons that I can't make truly browser independent web sites."
That's not going to change until this bug is reopened and corrected (and the correction propagates to the next
Netscape release, to boot.)
From my related, duplicate-marked, bug:
*****
One of the commentators in Bug 7543 says essentially that this is a feature, not a bug,
but I beg to differ. Said respondent .[rods; I didn't have the bug in qusetion in front of me
at the time - 20020306] suggests basically that the browser should just be
allowed to guess, since it uses a proportional (non-monospaced) font for text entry. This
strikes me as completely absurd. Using such a font is obviously a bug in and of itself (one
inherited unfortunately from most Windows browsers; I don't know of any other
browsers that have this problem), because unless a monospaced (non-proportional) font
is used, the SIZE attribute of INPUT TYPE="TEXT" is rendered completely and totally
useless. Secondary effects include mangling of carefully arranged layout (a problem
that's been vexing me enough to report it.)
I do not know if Mozilla for Windows or *n*x suffers from this problem. I note that
Netscape 4.x for Mac does NOT have this problem, and neither does IE 4.x or 5.x for Mac.
Both IE 4.x and NS 4.x for Windows have this or a similar problem (NS 4.x/Win has the
same problem, IE 4.x/Win. DOES use a monospaced font, but mis-sizes the field by about
3 or so characters anyway, at least on this test page.)
At any rate, text entry in any field the size of which is set in characters MUST necessarily
be in a monospaced font, or it breaks the functionality of this aspect of HTML.
*****
If rods is unwilling to fix it, is anyone else? Look at the comments here, and look at the number
of duplicates. This is obviously something that is bothering a lot of people.
So, if you care about this bug, vote for it, and if you're in a position to re-open it, please do so.
I appreciate that rods fixed the off-by-1 error, but that's actually a different bug than the one
at issue here.
PS: As noted elsewhere, I agree that IF an author does something to override what is (or
in Moz.'s case *should be*) the default behavior of making INPUT text be monospaced
(e.g. by assigning it a proportional font with styles), then but ONLY then is Moz.'s current
behavior sane (and it really is then - Mozilla wouldn't have much choice.)
PPS: I'm Cc'in seemingly interested parties from this and duplicate bugs, to hopefully
get some broader concensus on this. Right now it looks like a single individual has
effectively vetoed this bug getting ever fixed, over numerous objections.
Comment 29•23 years ago
|
||
Reopening.
We use "font: field;" for <input type="text"> and "font: medium -moz-fixed;" for
<textarea>. It seems to me we should be using the same font for both, and
Stanton McCandlish has given very good reasons why the default font for <input>
should be "-moz-fixed" rather than "field". The reason we don't use "field" for
<textarea>, of course, is that "it screws up too many pages".
The testcase in this bug is no longer applicable because it happens to use
characters which fit exactly in the width. Using capital "W" characters instead
of digits would demonstrate the problem immediately in the middle textfield in
the testcase.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 30•23 years ago
|
||
This is a testcase that has 3 size 5 text inputs with different font families
set (monospace, sans-serif, and serif).
Comment 31•23 years ago
|
||
This testcase tests the remaining problem -- a variable-width font being used
for <input> elements for which no font is specified. If a font _is_ specified
then what we do is correct. It is only when no font is specified that we get
odd behavior.
Attachment #4700 -
Attachment is obsolete: true
Attachment #14986 -
Attachment is obsolete: true
Attachment #19864 -
Attachment is obsolete: true
Attachment #19954 -
Attachment is obsolete: true
Attachment #72970 -
Attachment is obsolete: true
Comment 32•23 years ago
|
||
This is a screenshot of the just posted testcase.
This series of bugs has always been about nav4's rendering of text inputs where
it "doubles" the size of the box. Honestly, I do not see this anymore. Look
at the screenshot. Since Rod hooked up the strict sizing model (a year ago?)
and ditched the quirk width rendering in mozilla, I think that mozilla renders
this better than even IE6.
I'll post another testcase bumping the size to 50 and again you'll see that
mozilla renders this just like IE6 or better. I'm missing what the problem is
now?
Boris using "-moz-fixed" rather than "field" should be another bug report since
it is a different can-of-worms right?
Comment 33•23 years ago
|
||
The same testcase except that it now has size=50 instead of size=5.
To my eyes (without going to the pixel level) current mozilla build renders
just like IE6 in XP.
Comment 34•23 years ago
|
||
James, it is _not_ a separate can of worms. Read the opening comment on this
bug again. Then read the dups carefully. Both this bug and half the dups are
about the problem I'm talking about, which has nothing to do with what you're
talking about or what got "fixed" in this bug.
Assignee | ||
Comment 35•23 years ago
|
||
What exactly is the problem for why this bug was re-opened?
When comparing Moz to IE 6.0 the fonts for input type=text and textarea look
exactly the same. And we just aren't gooing to support NavQuirks anymore for
these. I am sure the user base of Nav 4.x is small and few sites are probably
developing for it, so I would rather have this discussion not focused on quirks.
So I did some sizing tests and we do size a little smaller than IE for inputs
and slightly bigger for textareas. The bottom line is "size=xxx" is meaningless
when you use a proportial font like IE and Moz does for inputs.
If the bug is open because you want us to get closer to how IE sizes, then that
is reasonable.
Comment 36•23 years ago
|
||
> The bottom line is "size=xxx" is meaningless when you use a proportial font like
> IE and Moz does for inputs.
Right, so why are we using a proportional font for inputs by default? We don't
do it for textareas...
Comment 37•23 years ago
|
||
Boris wouldn't this be better discussed with bug 53617 (comments 40 - 42 --
remember my email last week) or even better bug 106317 since that bug has
turned into a kind of general polish up of form controls (render consistent).
For example, you point to the fact that mozilla uses a fixed font for
textareas while everything else is proportional. Seems reasonable that
textareas should use the same font as the other controls.
Let's leave this bug just for size/width of text boxes.
Comment 38•23 years ago
|
||
OK. reading over all the relevant bugs I see that people can't make up their
mind as to what the hell they want in any of them. Reclosing this one; filed
specific bugs on specific issues:
Bug 130632 filed on the fact that on Mac the "field" font is unconditionally
mapped to "sans-serif".
Bug 130635 filed on the fact that on Linux the "field" font seems to sometimes
get mapped to "sans-serif".
Bug 130637 filed on the fact that none of the nice code from bug 53617, comment
53 is ever executed.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Comment 39•23 years ago
|
||
and verified, as it was (to be clear, verified that we now size pretty much like
IE in the case of variable-width fonts).
Status: RESOLVED → VERIFIED
Comment 40•23 years ago
|
||
James Lariviere wrote:
> mozilla uses a fixed font for
> textareas while everything else is proportional. Seems reasonable that
> textareas should use the same font as the other controls.
And, just to be clear, this should surely default to monospaced, so that the WIDTH attribute
of TEXT TYPE="INPUT" actually has any useful function in HTML at all, and only become
proportional/variable width IF the page author manually codes it that way. Right?
You need to log in
before you can comment on or make changes to this bug.
Description
•