698887 - Text positioning inside replaced inline elements is margin+border+padding+1px

Status: RESOLVED INVALID

(Core :: Layout: Form Controls, defect)

Description

[Andy Earnshaw]

Attachment: Test case

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.106 Safari/535.2

Steps to reproduce:

I created an <input> element, a <button> element and a <span> element, applying CSS styles to the <input> element.  Using JavaScript and `window.getComputedStyle()`, I copied *every* style value from the <input> element to the <button> and <span> elements.  I also set the <span> element's `display` to "inline-block".


Actual results:

All three elements look *almost* exactly the same, except that with the replaced elements, <input> and <button>, text positioning is 1px further from the left border of the input element.


Expected results:

Text position should be exactly the same in all three elements.  In the attached test case, you can see that only the <span> element's text is touching the vertical line, which is positioned at margin+border+padding (0+2+4=6px).  There is a 1px gap between the <input> and <button> elements and the vertical line.

Tested on Windows 7 only, may not apply to other operating systems.

Comment 1

[Boris Zbarsky [:bzbarsky]]

They're replaced elements.  You don't have any control about how they look on the inside.  That's what it means to be "replaced".

In particular, for the <button> there is a bit of padding from the ::-moz-focus-inner and the text input has internal structure that's not visible to the DOM that adds padding to allow better text legibility.

Comment 2

[Andy Earnshaw]

Boris, Internet Explorer/Trident manages to get them to look exactly the same.  We can style almost every aspect of an <input> and <button> element, and you're suggesting that we can't nudge the text over slightly to match how another element with exactly the same styles would look?

I don't understand why Gecko needs to add its own *internal* padding for text legibility - surely this is something a developer can do by tweaking the padding in their stylesheets?

There are very valid use cases for wanting a non-replaced element to be styled the same as a replaced element - for instance, a masked input that overlays an element containing the mask text allows said mask text to be styled alternatively to differentiate between the mask and actual input.  Granted, the work-in-progress I have doesn't look *too* bad, I just can't understand why I can't get it to look perfect without resorting to browser detection.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> Boris, Internet Explorer/Trident manages to get them to look exactly the same. 

Yep, because it violates CSS a bit in the process (e.g. changing the padding doesn't change the size in some cases).

> I don't understand why Gecko needs to add its own *internal* padding for text legibility

Because otherwise the scrolling behavior ends up wrong.  Again, IE doesn't use CSS for the scrolling in an input.  You may want to read bug 326123 and the bugs it references (which discuss the issue I mention above in detail), as well as bug 451574 (of which the text input part of this bug is a duplicate) and the discussion in bug 634649 for the general context here...

> There are very valid use cases

Sure.  They're also edge cases compared to "have basic typing functionality like a visible caret working", unfortunately.

> I just can't understand why I can't get it to look perfect without resorting to browser
> detection.

Because the behavior of replaced elements is, by definition, not defined by CSS.  So there is no spec for it and browsers do all sorts of weird things inside such elements to improve user behavior in the common case that may not interact well with CSS (e.g. see the thing about padding in IE)....

What you really want here is an actual spec for form control rendering; until that happens you likely won't be able to get pixel-perfect behavior here in general.

the existing bugs that analyze the behavior of the two in great detail; you can find them by looking at the revision history blame for the lines in forms.css that set the padding involved.