42821 - position of text in an input[type="text"] is off

Status: VERIFIED FIXED

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

Description

[James Lariviere]

DESCRIPTION:

The position seems off for text in an input[type="text"] where it starts 
horizontally and vertically.

STEPS TO REPRODUCE:

View test case.

In the test case, all borders are set to 1px and width of 200 px for the input
[type="text"] and <select>.

ACTUAL RESULTS:

Horizontal:
Notice how the input[type="text"]'s text start right against the left border 
while the <select> option has a little space between the left border.

Vertical:
Notice how the input[type="text"]'s text is higher than how the <select> 
positions its text.

EXPECTED RESULTS:

Rendering should be consistant.  I think the <select> renders "better" and more 
consistant with previous browsers (ie. text should render with a little left-
padding and be in the "middle" vertically instead of the upper 2/3rds as input
[type="text"]s do.


DOES NOT WORK CORRECTLY ON:

Win98 build 2000061520 (6-15-00-m17 I think)

Comment 1

[James Lariviere]

Attachment: test case

Comment 2

[Hixie (not reading bugmail)]

Confirmed. This can be made clearer using the default input text font -- James,
could you try to create a much more obvious test case? (i.e., one with more than
a few pixels of error?) Cheers.

Comment 3

[James Lariviere]

I would think that all I had to do was increase the line-height and font-size 
to demonstrate the vertical alignment problem.  Right?

This new test case seems to demonstrate that the text inside the <select> is 
positioned definately different than in the input[type="text"].

Comment 4

[James Lariviere]

Attachment: test case with larger font and line-height.

Comment 5

[Hixie (not reading bugmail)]

Much better, thanks. That really shows the problem clearly now.

Comment 6

[James Lariviere]

Wait I think that I might figured out what the heck is going on or atleast what 
might be causing this bug.  This bug something to do with the relationship of 
height and line-height.

If I set the line-height to a higher number lets say 2em, the <select> element 
height resizes larger to compensate for the larger line-height while the input
[type="text"] renders the line-height larger but the height stays the same 
(next test case).

Might this be the problem.  At larger sizes, the vertical position of the text 
input looks lower than the <select>. However, at smaller font sizes, because 
the text input doesn't take into account the line-height, might make the 
vertical alignment look too high. Right?

Comment 7

[James Lariviere]

Attachment: test case with line-height of 2em and font-size 2em

Comment 8

[James Lariviere]

I just noticed that if you set the height to a larger number (say 5em), the 
text input renders larger but the <select> element does not render with the 
larger height.  That seems wrong too.  Another test case :-)  enough for me 
today I think...

Comment 9

[James Lariviere]

Attachment: test case - setting height to 5em

Comment 10

[Hixie (not reading bugmail)]

Thanks James, you rock!

This is interesting. The test cases clearly show that problem is that we are 
treating <input> as a replaced element, which is (`traditionally') correct, but 
that <select> is being treated as an normal inline element.

The real solution would seem, to me, to be to treat <select> as a replaced 
element too, and then give both <input> and <select> a height of auto by 
default (html.css), and give them an inherent height equal to line-height 
internally. This would make them be the right size automatically, in a pure CSS
way. Does that sound right?

This would also solve the problem of the HTML "size" attribute conflicting with
the CSS 'width' property on INPUT elements -- make the inherent width of the 
text INPUTs be the width given by "size", and make the default width of INPUTs
be 'auto'.

However, note that these two elements DO have a baseline, so vertical-align:
baseline would make them align in such a way that the baseline of the text 
inside the text INPUTs or the SELECTs is the same as the baseline of the 
surrounding text. This is unlike IMG elements, for instance, that do not have
a baseline.

cc'ing David, who will know if I am talking nonsense or not.

Comment 11

[rods (gone)]

setting to M17

Comment 12

[rods (gone)]

reassigning, I think this is editor issue, the contents of the text control 
needs to be centered

Comment 13

[rubydoo123]

teh content shouldn't be centered, it should be left justified with some 
padding, asking Kin to take a look at this and get it over to the correct 
person.

Comment 14

[rubydoo123]

forgot to change the milestone

Comment 15

[kinmoz]

Accepting bug.

Comment 16

[James Lariviere]

I think that you need to look into what Ian Hickson wrote (last 6-16 message in 
particular).  In the test cases, you can see that the text in a <select> 
element is treated differently than an <input type="text">.  Look at the 
vertical alignment.  It is just off.

Fill out some forms on other sites, look carefully and you can see how the text 
in <input type="text"> looks like it is superscripted whereas the <select> 
right next to it looks baseline normal.

Again look at the test cases and see how the vertical alignment is rendered 
differently.  Why does the line-height (or height) change the rendering of one 
but not the other.  They do NOT work the same for either.

The other thing I wanted to point out is why padding is not described in em's 
or % so that if you increase font-size to say 50px's the padding adjusts 
instead of always the 2px's (or so) defined in html.css.

I also think that the padding should be equal for all form elements.  Why 
should a <select> have 3px's while a <input type="text"> has 2px's?  This just 
seems sloppy.

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Ian - I'm not sure we're getting the baseline correctly, despite that these do
have a baseline.  And, I'm not sure how we handle vertical-align on
inline-block-ish elements.  I haven't looked into your suggestions in detail
yet, either...

Comment 18

[rubydoo123]

Rod, the content inside is displaying fine, this has to do with the overall style 
of the form element, isn't that form controls?

Comment 19

[rods (gone)]

No, this isn't my issue. I now own the GetPrefSize method and any and all 
methods it calls. The GetPrefSize is responsible for the size of the 
GfxText. Since evaughan changed GfxText to use box layout I guess he or mjudge 
needs to fix where the "contents" frame is positioned inside the box frame. I 
find it rather aggrevating that all the form controls use "standard" layout 
mechanism and GfxText uses box layout.

I guess in a nutshell, the day evaughan changed to use box layout was they day I 
stopped owning that portion of the layout. Oh, and as module owner, I was never 
asked if it was ok to change it to box layout. It just happened and when it was 
originally checked in, it couldn't even layout out in NavQuirks. So I had to fix 
that also.

Comment 20

[rubydoo123]

ahh -- so we need to change module owner for form controls to evaughan! Eric, 
this is your baby now

Comment 21

[John Morrison]

mass-moving evaughan non-nsbeta3+ to Future milestone, per xptoolkit triage.

Comment 22

[James Lariviere]

This seems to me to be a rather MAJOR html form rendering problem to put off
since it messes up EVERY form page with input[type="text"] including this very
bug report page.

On this bug form look at the option to "reassign bug to".  the email address is
floating up (it's noticable) compared to the "resultion" <select> element 2
options above.

On other forms the email address really looks like its superscript text because
the font size AND position.

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

On NN 4.x Linux, both the selects and the inputs have their baselines properly
baseline aligned.  Is that not the case for Windows?

Comment 24

[James Lariviere]

The baseline for <select> and <input type=text> looks the same in NAV4.
However, since sometime this spring (beta1 timeframe) the baseline is NOT the
same in Mozilla for Windows.

The font family, size and text position (padding and vertical alignment) are
different between the 2 elements.

Type in "FIXED" into the "reassign bug to" text input and you can clearly see
the differences.

Comment 25

[James Lariviere]

I'm attaching a clipped screenshot from the bug# text input at the bottom of
this bug page to show how nav4/mozilla/ie5 render the baseline.

Comment 26

[James Lariviere]

Attachment: screenshot: comparing the default baseline rendering of text in inputs

Comment 27

[bsharma]

Updating QA contact.

Comment 28

[Vicente Salvador]

Why default <input type="text"> has so many "extra space" on the top and the 
bottom of the text.

I know my purposse is a "look&feel" flavour but I like small form controls that 
allows to save space on the browser window. I think 1 px at the top and the 
bottom of the text into the input fields is enough, maybe like IE form controls.

Comment 29

[James Green]

Hmm If I do something like:

<form action="somepage.phtml" method="post">
This is a line of text <select name="selme">
<option>Take 1</option>
</select>
</form>

The Select list looks superscripted (i.e. high on the line). This also affects
<input type="text"> and <input type="submit">. Now if I use style="position:
relative; top: 6px;" in the select element it displays correctly, but of course
that depends on the font size being fixed.

Is this problem what this bug covers? I'm not entitely certain, so if it's not
someone prompt me to file a new bug.

Comment 30

[Vicente Salvador]

Yeah, But I think the real problem is not on vertical align of text. I think 
that the problem is because controls are so much high and wide. Making forms not 
so tall will solve this bug.

Comment 31

[rods (gone)]

Attachment: image of comparison between Mozilla in Nav Quirks and Nav 4.x

Comment 32

[rods (gone)]

Take a close look at the image. Mozilla is on top, Nav 4.x is on the bottom. A 
very important thing to note is that the border of Nav 4.x (native control) is 3 
pixels and Mozilla's is only 2 pixels. The three pixel border on the native 
control to the user looks more like only 2 pixels. If in mozilla we set the 
border to 3 pixels, it does look larger than the native 3 pixel border.

We couldn't easily duplicate the way they draw the border, so we have to make 
ours 2 pixels, which means there is an extra pixel of white space all the way 
around the text, but the two control are exactly the same size on the outer edge 
of the control.

Mozilla:
3 pixels from outer edge to the left of the text
7 pixels from outer edge to the top of the text

Nav 4.x:
5 pixels from outer edge to the left of the text
8 pixels from outer edge to the top of the text

So the text nees to be shifted left 2 pixels and down 1 pixel, but the isze is 
the same.

If you want small narrow/thin text controls you should use a "strict.dtd" the 
sizing is different.

Comment 33

[Peter Trudelle]

->moz0.9

Comment 34

[Vladimir Ermakov]

QA Contact Update

Comment 35

[Eric Vaughan]

Vertical seems to have already been fixed. But horizontal was off my a single
pixel. So I just added a single pixel of padding in. Here is the diff:

cvs server: Diffing .
Index: nsGfxTextControlFrame2.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/html/forms/src/nsGfxTextControlFrame2.cpp,v
retrieving revision 1.130
diff -r1.130 nsGfxTextControlFrame2.cpp
1659,1660c1659,1660
< #define DIV_STRING "-moz-user-focus: none; border: 0px !important; padding: 0p
x; margin:0px; "
< #define DIV_STRING_SINGLELINE "-moz-user-focus: none; white-space : nowrap; ov
erflow:auto; border: 0px !important; padding: 0px; margin:0px"
---
> #define DIV_STRING "-moz-user-focus: none; border: 0px !important; padding-lef
t: 1px; padding-right: 1px; padding-top: 0; padding-bottom: 0; margin:0px; "
> #define DIV_STRING_SINGLELINE "-moz-user-focus: none; white-space : nowrap; ov
erflow:auto; border: 0px !important; padding-left: 1px; padding-right: 1px; padd
ing-top: 0; padding-bottom: 0; margin:0px"

Comment 36

[Peter Trudelle]

Eric is not going to have time to get to do this for 0.9.  Moving to 0.9.1,
adding helpwanted keyword.

Comment 37

[Ryan Frishberg]

Hey guys,

Along with this, here's another thing that makes this difference very, very 
obvious.

By using line-height, I've noticed all child form elements are aligned on the 
bottom no matter what the CSS property, vertical-align, is set to.  Example:

<div style="line-height:200px;vertical-align:middle"><form>Here's some text 
<input type="text"><select name="select" style="height:20px"><option>1st 
option</option></select></form></div>

In this example, the text is properly aligned in the middle of it's parent DIV 
element, but the form elements are aligned at the bottom.  Also, if you notice, 
the select element doesn't show the option; instead, the option is aligned in 
the center (click on the select box to see what I mean).

I hope this helps to clarrify this important bug.

Comment 38

[Ryan Frishberg]

Attachment: Form Elements automatically align at the bottom

Comment 39

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The 'vertical-align' property is not inherited and doesn't really apply to
blocks.  Try specifying it for the element that you want to align.

Comment 40

[Ryan Frishberg]

Attachment: Form Element still won't vertically align property

Comment 41

[Ryan Frishberg]

David,

You are right...  In the last example I erroneously set the vertical-align to 
center (rather than middle).

After doing such, it works fine.

Comment 42

[James Lariviere]

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

Comment 43

[Peter Trudelle]

->mjudge, per evaughan

Comment 44

[mjudge]

looks fine to me. Did you want me to check it in from my tree eric? 

Comment 45

[Petrus Lundqvist]

Not so fast.. It's not just a matter of being aligned to the top instead of the 
bottom. The whole input field is too tall. Maybe there's extra padding at the 
bottom or whatever, but the result is that there is STILL more spacing on the 
bottom than on the top and the whole input field is taller than in IE or NS4.

Comment 46

[James Lariviere]

I think rod is tired of my bug reports dealing with this issue. ;-)

The problem with what "looks like larger" text inputs is that nav4 rendered with
a 3px bottom border (dumb) so rod did the "correct thing" and made borders all
2px's.  Take a screenshot and zoom in to compare.

Mozilla are doing the "right" thing because it is trying to renders like nav4 in
quirks mode except the vertical alignment just needs to go down by a pixel.  A
quick one line change.

If you want your text inputs to look more like IE you have to use strict mode. 
I know because my sites use strict now. :-)

Comment 47

[rubydoo123]

handing this back t Eric

Comment 48

[Peter Trudelle]

->moz1.0

Comment 49

[basic]

currently in quirks.css I see

input[type="text"]{
  padding: 1px 0 0 0;
}
and

td input[type="text"], input[type="password"] {
  margin-top: 1px;
  margin-bottom: 1px;
}

my suggestion is to remove those 2 and replace them with

input[type="text"], input[type="password"] {
  padding-top: 2px;
  padding-left: 2px;
  margin-top: 1px;
  margin-bottom: 1px;
}

I find that with my suggestion it works as expected. James could you verify?

Comment 50

[James Lariviere]

Yes it does work :-) but there are other changes that will be required in other
files.  Look at the address bar, its position is now off (down too far).  Have
no fear though... check out bug 69130.  Rod Spears patch from 2-21 should give
you a hint of the needed changes.

Nice one!

Comment 51

[James Lariviere]

Attachment: screen shot of proposed initial patch (before/after)

Comment 52

[basic]

hmm... why is the address/url bar depending on html? Even worst quirk html?
James I'm not sure I understand your problem with the address/url bar, could you
post a before/after screenshot?

Comment 53

[basic]

James: did you change the properties in quirks.css or forms.css ?

Comment 54

[basic]

err make that "quirk.css"

Comment 55

[basic]

Attachment: proposed patch

Comment 56

[basic]

Though this is suppost to be a Win9x only bug, I think it would be better if the
patch is tested on other OS like Mac and Linux and wherever NS4 exists ;)

Comment 57

[James Lariviere]

Sorry, I was on crack or something (mountain biking on my mind;-])!
Damn, I can not believe I did not think of this.

[e-mail] can we get a review on this?  Thanks.

Comment 58

[James Lariviere]

Attachment: linux screenshot of google with patch

Comment 59

[basic]

Attachment: css file for to be attached testcase

Comment 60

[basic]

Attachment: testcase that allows comparing current display and proposed

Comment 61

[basic]

could someone test the testcase I just posted in linux/mac ns4/moz ?

Comment 62

[basic]

James: I just realize that my patch doesn't fix the <select> problem mentioned
in this bug. I've not taken a look at it, could you point me to a testcase that
show the problem for that if it (the problem) still exist?

Comment 63

[Alvaro Munoz-Aycuens]

Added screen captures of Basic testcase in Linux and MacOS

http://www.aycuens.com/mozilla/linuxmoz_42821.jpg
http://www.aycuens.com/mozilla/linux4x_42821.jpg
http://www.aycuens.com/mozilla/macmoz_42821.pict 
http://www.aycuens.com/mozilla/mac4x_42821.pict

Comment 64

[basic]

After taking a look at the linux and mac screenshots, I think that the ns4
displays on those platforms are not worth emulating (except maybe the the round
bullets for password fields in the mac, but I think that would be part of
another bug ;-) ).

Alvaro: thanks for the screenshots, but next time could you make sure that the
linux screenshots are in png and mac screenshots are not sized down. Don't need
to post anymore screenshots, I don't think we need to be compatible with NS4
mac/linux (I think that most users would appreciate Moz's new rendering ).

James: does the <select> still have problems? If so please explain with a
screenshot or a testcase to me. If not the patch is ready for checkin.

Comment 65

[James Lariviere]

I think that Hixie's comments from 6-16-2001 is probably the most important part
of this bug report (long-term) but I think that is a different bug now (see bug
79541).

Your patch fixes the default rendering I was complaining about.  Nice One.

This is a very obvious polish fix for any page that has these form controls.
Checkin Review Please r= sr=

Comment 66

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Isn't one of the underlying problems here that there's C++ code that's hard
coding the size calculation for the actualy box that makes the text input, and
that that code ignores many CSS properties that actually do affect what's inside
the input?

(Frankly, I'd rather work on rewriting the form controls in XBL (perhaps even
with native alternatives) than trying to tweak the current ones so that they
work "right".)

Comment 67

[James Lariviere]

So we should concentrate on bug 57209 and leave this one rule fix alone? :-)

Comment 68

[basic]

dbaron: if you can garantee that xbl form controls will be implemented before
the next major NS6.x release, I wouldn't make a fuss about this. But if that is
not going to make it, I'd want to see this very very simple patch go in.

Comment 69

[Petrus Lundqvist]

I am no longer seeing this with the latest nightly builds on Win32..

Comment 70

[James Lariviere]

You're right.

Rod fixed this when he "removed" the sizing quirks so now mozilla renders in 
strict mode.

Unless rod puts back the quirky sizing... this is fixed as I reported it 1.5 
years ago.  :-)  marking.

Comment 71

[Vladimir Ermakov]

verifying on 2001-10-12-05-branch windows 98