451574 - CSS Form Text Input Padding

Status: RESOLVED DUPLICATE of bug 157846

(Core :: Layout, defect)

Description

[Robin Dean]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1

My HTML:

<input type="text" id="form_email" class="form_text" name="email" value="Your Email Address">

My CSS:

.form_text {
width: 138px;
height: 17px;
border: 0;
padding: 4px 6px 0;
margin: -1px 0 0 -1px;
background: transparent;
color: #764520;
font: 11px verdana, sans-serif;
}

All of my other browsers (about 8 or 9 total) display the padding (both vertically and horizontally) correct, including FireFox 2.

FF3 is adding an extra pixel to the padding.

Reproducible: Always

Steps to Reproduce:
1. Create a page with my input
2. Create a stylesheet with my css
3. Compare in different browsers.
Actual Results:  
Extra pixel of padding in ff3.

Expected Results:  
Specified padding.

Comment 3

[Robin Dean]

Really? Nobody has even poked at this issue? I hope this bug is covered in the next release.

Comment 4

[Boris Zbarsky [:bzbarsky]]

See bug 326123.  IE on Windows has basically the same behavior, as I understand.

Comment 5

[Robin Dean]

IE version 7+ does NOT.

Comment 6

[Boris Zbarsky [:bzbarsky]]

So if you don't set padding at all there's no 1px left padding for the bidi marker on the caret?  That's not what I recall seeing last time I tested IE...

Comment 7

[Robin Dean]

All I know is that My version of IE7 with a default config doesn't show the it when the padding IS defined.

I'm not interested in discussing IE anyhow. Even more so, I've given up and switched to flash forms because FF3 is in a failed state as far as form based css is concerned.

It renders incorrectly and has failed itself in comparison to FF2.

Thus, I'm unsubscribing from this thread because they obviously don't pay any attention to these things and have no intention of correcting their mistake.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Robin, the point is that we need to be compatible with IE when padding is not set (common case), because that's needed for useful internationalization support.

We'd like to be compatible in general, as far as it makes sense.

For what it's worth, there is no specification for what CSS should do when applied to form controls, so depending on it doing anything in particular is sort of dangerous...

Comment 9

[Boris Zbarsky [:bzbarsky]]

Martijn, what does IE actually do here?

Robin, one more thing. _You_ may not care to discuss IE, but in practice you're depending on its behavior and expecting us to replicate it.

Comment 10

[Martijn Wargers (dead)]

Attachment: testcase

Comment 11

[Martijn Wargers (dead)]

Attachment: results that I get

This is tested with the classic them on windowsXP.
As you can see, I don't get any difference between Firefox 2 and Firefox 3.
Indeed, for the case when no padding is defined, Firefox behaves the same as IE8, but not when padding is defined.

I guess ideally Firefox should behave the same as IE8, when padding is set, but that's probably related to bug 157846.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Sorta.  We make a distinction between the padding on the input and the padding on the anonymous block inside; we have 1px padding on the latter to make the direction marker thing work right.

See bug 326123 and the bugs linked from it for the reasons behind the behavior.  In particular note that we have to emulate IE's behavior as far as the size of he control with no padding styling goes.  So that means either putting the default padding on the anonymous div, or emulating IE's "changing the padding doesn't change the size" insanity or adjusting the default size by the default padding somehow.  We do the first of those, which means that the padding is added to the default input padding.

Frankly, I think that's the best solution (which is why we did it), but if someone wants to make the "adjust the default size" thing work somehow, go for it.

Comment 13

[mkyoon]

Attachment: funny input's height

it's randomly occured. (mouse right click -> refresh)
Expected "Element Height" = height:15px + padding-top:3px + border: 2px = 20px.
But "Element Height @ Screenshot" = 15px.

Comment 14

[Martijn Wargers (dead)]

mkyoon, with which testcase did you make that screenshot? It doesn't seem like that is related to this bug at all.

Comment 15

[mkyoon]

oops! I've come to wrong address, sorry.

Comment 16

[Alex Henrie]

I ran the testcase and as far as I can tell, this is a duplicate of bug 157846, which is now fixed.