188324 - The height of <Input Type=Text> is larger than specified

Status: RESOLVED INVALID

(Core :: Layout: Form Controls, defect)

Description

[Ivan Sagalaev]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030107
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030107

The height of text inputs is larger than the one set in style by 5 pixels. The
following testcase shows difference between a text input and a button side by side.

Reproducible: Always

Steps to Reproduce:
1. Look at the test case
2. Note the difference in height between the input field and the button
3.

Actual Results:  
The text input is higher than the button by 5px

Expected Results:  
Elements' height sholud be equal

Comment 1

[Ivan Sagalaev]

Attachment: testcase

Comment 2

[Ivan Sagalaev]

Ah... things are a bit worse :-). The difference is actually 4 pixels. But the
button is _positioned_ 1 pixel higher then the text input.

Comment 3

[Ruslan Ismailov]

Hmm strange. Work for me on WinXP Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.3b) Gecko/20030104. Is it a regression?

Comment 4

[Ivan Sagalaev]

Then it looks like an issue with OS drawing on Win 2000. I'll attach a screenshot.

Comment 5

[Ivan Sagalaev]

Attachment: screenshot on Windows 2000

Comment 6

[José Jeria]

This is on XP also, both classic and xp style. Build 2003010805.

Comment 7

[Boris Zbarsky [:bzbarsky]]

This is a "regression" in that we now, in standards mode, use content-box sizing
for text inputs (so "height" is height of content") while using border-box
sizing for buttons (so "height" is height of content + padding + border).  We
used to use border-box sizing for both, but IE6 has started approaching the CSS
standard on the issue and we're tracking the changes they made (pending a
reevaluation of all the form sizing stuff).

The only issue I see here is the issue of 1px mispositioning.... does that
happen if you do not set the heights?

Comment 8

[Boris Zbarsky [:bzbarsky]]

oh, see bug 184478 for more information

Comment 9

[Ivan Sagalaev]

> This is a "regression" in that we now, in standards mode, use content-box sizing
> for text inputs (so "height" is height of content") while using border-box
> sizing for buttons (so "height" is height of content + padding + border).

But... Uhm... Doesn't it break standard compliance than? I believe CSS spec says
'height' should be used only for content without padding, borders, margins
without exceptions. Am I missing somehting?

And as you've touched the issue... What is now the politics in standard
compliance in strict mode? Are we copying IE's behaviour in some things or
adhere the specs everywhere?

> We used to use border-box sizing for both, but IE6 has started approaching the CSS
> standard on the issue and we're tracking the changes they made (pending a
> reevaluation of all the form sizing stuff).

In fact IE renders the testcase differently: it aligns input and button by
bottom. (I'll attach another screenshot for convinience)

> The only issue I see here is the issue of 1px mispositioning.... does that
happen if you do not set the heights?

They are aligned and sized correctly without 'size' AND without 'padding' set.
With 'padding:0' and without 'size' button's top is  1px higher and bottom is
1px lower :-)

Extended testcase follows.

Comment 10

[Ivan Sagalaev]

Attachment: Extended testcase

Testcase with different 'height' and 'padding' options

Comment 11

[Boris Zbarsky [:bzbarsky]]

> Am I missing somehting?

Yes. You're missing the fact that form controls are replaced content which is
not really specifiable via CSS (how do you style the file control usefully?).

You're also missing the use of a proposed CSS3 property that controls this (the
border-box/content-box is not hardcoded; it can be changed by the
-moz-box-sizing property).

> In fact IE renders the testcase differently:

Yes, I know.  We baseline-align the controls instead of bottom-aligning, since
it looks better.

> With 'padding:0'

all bets are off.  Again, we align the baselines of the text in the controls, as
much as possible (once you assign a height, this breaks since buttons center
vertically while text inputs do not; this does not affect the baseline
locations, however).  The outer edge is determined then by how much padding and
border the controls have.  See
http://lxr.mozilla.org/seamonkey/source/layout/html/document/src/forms.css#77

So we come back to the fact that the internals of form controls (like the border
and padding) should simply not be stylable... we keep trying to make that so,
but people are insisting that they be given the chance to shoot themselves in
the foot.

Comment 12

[Ivan Sagalaev]

Attachment: Screenshot in Mozilla and IE6 side by side

Comment 13

[Ivan Sagalaev]

> You're missing the fact that form controls are replaced content 

Oops.. Thank you for pointing this.

>> With 'padding:0'
>
> all bets are off.  Again, we align the baselines of the text in the controls,
> as much as possible (once you assign a height, this breaks since buttons 
> center vertically while text inputs do not; this does not affect the baseline
> locations, however).  The outer edge is determined then by how much padding
> and border the controls have.  
> See http://lxr.mozilla.org/seamonkey/source/layout/html/document/src/forms.css#77

Understood.

> So we come back to the fact that the internals of form controls 
> (like the border and padding) should simply not be stylable... 
> we keep trying to make that so, but people are insisting that they 
> be given the chance to shoot themselves in the foot.

Ah... I remember this discussion in the bug 134927 :-). But this is another
story. Clearly, the ability of styling some controls are widely required and
used and usually web developers don't care about styling file upload or radio
controls.  Perhaps they don't know what to expect from certain user agent given
'width:200px; height:10px;' on radio button, so they just don't use it. But
styling of text inputs, buttons, select's options is much clearer. That's why
this issues are raised continuously.

Anyway, thank you again for clearing things up. Since <Input Type=Text> is a
replaced element one can not require any strictly defined behavior when using
dimension style settings. I believe this is WONTFIX then?

Comment 14

[Ivan Sagalaev]

One related question:

Using <Input Type=Text Style="Border-Width:1px;"> doesn't actually affect the
border's width but shrinks the input vertically instead. Is this the same issue
as in bug 184359 or it's another one?

Comment 15

[Boris Zbarsky [:bzbarsky]]

Yep.  That's bug 184359

Comment 16

[Ivan Sagalaev]

Resolving this INVALID based on Boris Zbarsky's explanation.

Comment 17

[Ivan Sagalaev]

BTW, I need a clarification about who should verify/close the bug? Reporter or
QA contact may be?

Comment 18

[Boris Zbarsky [:bzbarsky]]

QA contact, typically.