Closed Bug 451574 Opened 16 years ago Closed 10 years ago

CSS Form Text Input Padding

Categories

(Core :: Layout, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 157846

People

(Reporter: email, Unassigned)

References

Details

Attachments

(2 files, 1 obsolete file)

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.
Component: Build Config → Layout
Product: Firefox → Core
QA Contact: build.config → layout
Really? Nobody has even poked at this issue? I hope this bug is covered in the next release.
See bug 326123.  IE on Windows has basically the same behavior, as I understand.
IE version 7+ does NOT.
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...
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.
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...
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.
Attached file testcase
Attached image 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.
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.
Attached image funny input's height (obsolete) —
it's randomly occured. (mouse right click -> refresh)
Expected "Element Height" = height:15px + padding-top:3px + border: 2px = 20px.
But "Element Height @ Screenshot" = 15px.
Attachment #341732 - Attachment description: Mozilla/5.0 (Windows; U; Windows NT 5.1; ko; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3 → funny input's height
mkyoon, with which testcase did you make that screenshot? It doesn't seem like that is related to this bug at all.
Attachment #341732 - Attachment is obsolete: true
oops! I've come to wrong address, sorry.
I ran the testcase and as far as I can tell, this is a duplicate of bug 157846, which is now fixed.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: