Closed Bug 25657 Opened 25 years ago Closed 22 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)

Product:
Core
Component:
Layout: Form Controls
Platform:
All
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: edmanet, Assigned: rods)

References

(
URL
)

Details

Attachments

(3 files, 5 obsolete files)

Testcase that is actually relevant
587 bytes, text/html
Details
screenshot of testcase -- WinXP IE6 and Mozilla 3-4-2002 build
27.08 KB, image/png
Details
testcase -- size=50
710 bytes, text/html
Details 
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...
Reassinging to Rod.
Assignee: karnaze → rods
Attached file simple test (obsolete) — 

    
    

    
  
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

    
    

    
  
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

    
    

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

    
    

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

    
    

    
  
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.


    
    

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

    
    

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

    
    

    
  

      
      
      
      

        Attached file
          
        test with 3 INPUT elements (obsolete)
        — 
      

    


  

    
    

    
  
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.

    
    

    
  
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.

    
    

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

    
    

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

    
    

    
  
Please see attach 19864 - this bug is NOT invalid, I think.

    
    

    
  
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.

    
    

    
  
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 → ---

    
    

    
  
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

    
    

    
  
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.

    
    

    
  
rods patch looks good.
r=kmcclusk@netscape.com

    
    

    
  
sr=waterson

    
    

    
  
fixed the one char too big problem when in standard mode.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED

    
    

    
  
->gerardok
QA Contact: ckritzer → gerardok

    
    

    
  
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 !


    
    

    
  
verified on build 2001-08-14-trunk
Status: RESOLVED → VERIFIED

    
    

    
  
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.

    
    

    
  
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 → ---

    
    

    
  

      
      
      
      

        Attached file
          
        testcase (obsolete)
        — 
      

    


  
This is a testcase that has 3 size 5 text inputs with different font families
set (monospace, sans-serif, and serif).

    
    

    
  


  
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

    
    

    
  


  
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?

    
    

    
  

      
      
      
      

        Attached file
          
        testcase -- size=50
        — 
      

    


  
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.

    
    

    
  
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.

    
    

    
  
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.



    
    

    
  
> 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...

    
    

    
  
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.

    
    

    
  
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 → 22 years ago
Resolution: --- → FIXED

    
    

    
  
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

    
    

    
  
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.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: