Changing the line-height of ::placeholder affects the vertical alignment of its text
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
People
(Reporter: john.emau, Unassigned)
References
()
Details
(Keywords: testcase)
Attachments
(7 files)
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36 Steps to reproduce: I applied styling for the line-height property using the ::-moz-placeholder selector on an input element which had a height greater than the default height for an input element. Bug reproduces in the following codepen: http://codepen.io/anon/pen/sJEHm Actual results: The placeholder text became miss-aligned, the text was appeared to be aligned with as if the input element height was still it's default height. Expected results: The placeholder text should be vertically middle aligned.
Reading that Firefox ignores line-height on an input element, I recommend doing the same when styling placeholder text. link: https://developer.mozilla.org/en-US/docs/Web/CSS/line-height
Regression range: good=2012-11-09 bad=2012-11-10 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=90cea19e27e2&tochange=a47525b93528 My guess goes to bug 737786. It looks like an old issue, surely already reported.
Comment 6•10 years ago
|
||
This is the expected behavior given the styles in the testcase. The input has an anonymous block inside which has a line height set to the input height. This is done to vertically center the text. The testcase is not changing this line height, since it's not applying styles to this block. The placeholder also has such a line height, but the testcase is explicitly overriding that style. That means it's explicitly disabling the vertical centering.
Comment 7•10 years ago
|
||
Note that webkit's placeholder implementation is different in all sorts of ways. In particular, changing its line-height doesn't change its height (but does change the vertical alignment of the text inside the placeholder box!), styling its height also doesn't change its height, and the actual placeholder block is always vertically centered on the input. I personally don't think we should be making random changes here until this is standardized.
Comment 10•3 years ago
|
||
Nowadays, all other major browser engines (Blink & WebKit) have the requested behavior here -- vertically centering the placeholder text, even if it has a specified line-height
that disagrees with that of the <input>
element.
We should probably figure out what other impls are actually doing here, and aligning (and ideally standardizing) a bit better with them here.
Comment 11•3 years ago
|
||
Comment 12•3 years ago
|
||
Comment 13•3 years ago
|
||
Comparing today's major rendering engines, with my just-attached testcase and reference case:
- Chrome 90 renders the attached testcase and reference case the same (centering the text vertically in both cases).
- Firefox 87 pushes the text downwards (and clips it) in the testcase.
- Safari 14 pushes the text downwards (and clips it) in the reference case.
Comment 14•3 years ago
|
||
(Here's a screenshot of this bug causing trouble at https://www.rei.com/rei-garage , in the enter-your-email field at the bottom of that page. That's what caused me to dig into this a little bit this evening.)
Comment 15•3 years ago
|
||
https://github.com/w3c/csswg-drafts/issues/2282 (bug 1686513) might be semi-relevant here, too. That's about a CSSWG resolution on line-height
being a bit more authoritative for the sizing of ::first-line
; and the ::placeholder
pseudo is defined as honoring all of the same properties as ::first-line
as noted here, and might reasonably want to change it's behavior a bit in response to that resolution (particularly if it helps make sense of interop bugs like this one.)
Updated•3 years ago
|
Updated•3 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 16•15 days ago
|
||
Firefox now vertically centers the text here on the codepen and testcase, so this has since been fixed.
It was fixed in bug 1714631.
Comment 17•15 days ago
|
||
(In reply to Thomas Wisniewski [:twisniewski] from comment #16)
It was fixed in bug 1714631.
Thanks! Looks like we can consider this a dupe of bug 1714631, really, rather than an incidental thing that happened to be fixed by it. Let's mark it as such.
Description
•