69130 - [MF][FIX]input[type="text"] content area height is too large

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[James Lariviere]

DESCRIPTION:

The content height (area between top/bottom borders) for input[type="text"] is
larger than in selection[size="1"].


STEPS TO REPRODUCE:

I am attaching a screenshot to demonstrate this problem.

In the screenshot (taken from the bug report page), I copied the rendering of a
select and an input from each browser: mozilla winbuild 02-15, nav4.08, and ie5.

ACTUAL RESULTS:

by default,
NAV4 renders the select box (18px's high) and the text input (18px's high);
IE5 renders the select box (18px's high) and the text input (18px's high);
Mozilla renders the select box (18px's high) and the text input (20px's high);

EXPECTED RESULTS:

Mozilla should render the content area the same height for select and text
input.  This I think gives a more consistant, polished look. :-)

This might be related to bug 42821 (text position is off for the
input[type="text"]) or might be causing it.


DOES NOT WORK CORRECTLY ON:

Win98 build 02-15-05

Comment 1

[James Lariviere]

Attachment: screenshot of renderings by mozilla/nav4/ie5

Comment 2

[rods (gone)]

Attachment: screen shot

Comment 3

[rods (gone)]

Well you really need to blow it up to see what is going on. And there isn't a 
week that doesn't go by that I don't have to explain this. Although, I think 
there is a msall problem here in strict/standard mode.

            Outside   Inside  Border
-----------------------------------
Moz Quirk   169x24    165x20  2px
Nav 4.x     169x24    163x18  3px
IE 5.x      153x22    149x18  2px
Moz Strict  144x20    140x16  2px

Note: The outside measurement of Moz in quirks mode matches exactly with Nav 4.x
I think a small bug here is to have Moz in Strict mode match the height of IE 
and it would be nice if the width would match, but I have never been able to 
figure out what algorthim they are using.

I think there is currently a bug on evaughan to fix the positioning of the text 
inside the text control. It needs to be down one pixel.

Comment 4

[rods (gone)]

Here is the patch:
Index: forms.css
===================================================================
RCS file: /cvsroot/mozilla/layout/html/document/src/forms.css,v
retrieving revision 3.6
diff -u -r3.6 forms.css
--- forms.css   2001/02/07 00:39:29     3.6
+++ forms.css   2001/02/16 23:04:46
@@ -70,6 +70,7 @@
   -moz-box-sizing: border-box;
   -moz-user-focus: normal;
   moz-binding: 
url("resource:///res/builtin/platformHTMLBindings.xml#inputFields");
+  padding: 1px 0 1px 0;
 }

 textarea {
@@ -218,6 +219,7 @@
   font-family: sans-serif;
   font-size: small;
   -moz-binding: none;
+  padding: 0 0 0 0;
 }

 input[type="image"][disabled] {
@@ -234,6 +236,7 @@
   border: none;
   cursor: default;
   -moz-binding: none;
+  padding: 0 0 0 0;
 }

 /* button part of file selector */
@@ -252,6 +255,7 @@
   vertical-align: baseline;
   -moz-border-radius: 100%;
   -moz-binding: none;
+  padding: 0 0 0 0;
 }

 /* check boxes */
@@ -265,6 +269,7 @@
   vertical-align: bottom;
   -moz-binding: none;
   margin: 3px 4px 3px 4px;
+  padding: 0 0 0 0;
 }

 /* common features of radio buttons and check boxes */

Comment 5

[James Lariviere]

rod, just so you know the reason why i reported this bug is that when you put a
select and a text input side by side, the text input is larger(in height) than
the select in mozilla quirky. I thought it looked odd.

FYI, this bug is really about the content height not the width. (I've read too
many reports about the variable width sizing issues with text inputs.)

Your stance is that Mozilla (in quirks mode) instead of rendering a 3px t/b
border, it (mozilla renders it 2px) will make up the difference in the content
height so mozilla will render the same overall height of the text input as NAV4?

IMHO, I was kinda hoping that you would not add the extra 2px from the border to
the content height, so that mozilla would render the same height as the select. :-)

BTW, evaughan is working on my bug 42821 (text position is off in
input[type="text"]).  Could this be the reason why the text position looks off?

Are you going to try to land this in the moz0.9 timeframe?

Comment 6

[rods (gone)]

The important thing is that the outside border measure the same height in Moz 
Quirks as Nav 4.x. Which is does (24px). The problem is, the way the native 
borders are drawn they use 3 px border and visually it only loks like 2px. So we 
use 2px border and then we have an extra pixel top and bottom and we have to add 
that to the content area (we have no choice). I think it looks worse because the 
text inside is positioned incorrectly (the evaughan bug).

In Nav quirks mode the text is 2px highter than the select, which is the same in 
Moz. Another problem you have uncovered, is that the margin is set wrong for 
selects. The margins should be set to zero.

Comment 7

[rods (gone)]

Attachment: latest patch file

Comment 8

[James Lariviere]

thanks rod,

Just an thought. Maybe the select field margin was put there so that it would
equal the total height of the text input --

18px (content) + 4px (t/b border) + 2px (t/b margin) = 24px.

Why not do the some for the input[type=text]?

Comment 9

[James Lariviere]

rod,

one other thing...

When I added your changes to my forms.css file, I noticed that it changed the
text position in the mozilla address field. (no really :-))

I'll put up a screenshot. (In the screenshot, the address seems too low and then
when you select any part of the address, the texts shifts up.)

There is probably some rule in the skin that needs to be changed when you check
this patch in. Or maybe the rule should just be taken out of the skin?

THis was the only place I noticed "odd" positioning.

Comment 10

[James Lariviere]

Attachment: screenshot - comparing mozilla address bar text positions

Comment 11

[rods (gone)]

Attachment: patch for chrome issues

Comment 12

[James Lariviere]

rod, you know I hope that this will also fix that lame/weird looking checkbox
and radio :focus {border-style:groove} junk (added sometime last fall).

You select a radio or checkbox and that groove style just looks sooooooooooo out
of place. :-)

Comment 13

[Kevin McCluskey (gone)]

Setting milestone to mozilla0.8.1

Comment 14

[Vladimir Ermakov]

QA Contact Update

Comment 15

[David Hyatt]

sr=hyatt

Comment 16

[Kevin McCluskey (gone)]

r=[e-mail]

Comment 17

[rods (gone)]

fixed

Comment 18

[James Lariviere]

looks good.  thanks rod :-)
should be interesting to see if 3rd party skin authors fix their skins...