Vertical padding influences baseline alignment of text around span with "vertical-align:middle" (only in Firefox)
Categories
(Core :: Layout: Block and Inline, defect, P3)
Tracking
()
Webcompat Priority | P3 |
People
(Reporter: dholbert, Unassigned)
References
Details
(Whiteboard: [webcompat])
Attachments
(2 files)
(I'm not 100% sure who's correct here, but filing because we differ from all other major browsers on this -- so even if we happen to be correct, there's a webompat concern.) STR: 1. Load attached testcase. EXPECTED RESULTS: Consisten text position within each box. ACTUAL RESULTS: In the first orange box, "AAA" and "CCC" are pushed lower than "BBB". In the second orange box, "BBB" is pushed lower. Latest Chrome, Edge, and Safari give "expected results". Firefox gives "actual results". This is the underlying issue in this webcompat bug: https://github.com/webcompat/web-bugs/issues/12629
Reporter | ||
Updated•6 years ago
|
Reporter | ||
Comment 1•6 years ago
|
||
Reporter | ||
Comment 2•6 years ago
|
||
This testcase is a bit more interesting, with different font sizes. At first glance, I think: - Chrome is honoring "vertical-align:middle" by lining up the center-line of the span's *line box* (excluding its padding) with the center-line of the line that it's participating in. (i.e. "AAA" is vertically centered with respect to the bounding box of the "BBB" text, and vice versa) - Firefox is doing the same, except that it's *includes the padding* (and probably border) when determining the center-line of the span. (i.e. "AAA" is vertically centered with respect to the *purple border-box* around "BBB")
Comment 4•5 years ago
|
||
Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.
Comment 5•5 years ago
|
||
See bug 1547409. Migrating whiteboard priority tags to program flags.
Updated•4 years ago
|
Reporter | ||
Comment 6•2 years ago
•
|
||
I just ran into this bug at Fidelity's website (Mozilla's retirement 401k account provider, in the US)
STR there:
(1) Sign in at https://nb.fidelity.com/public/nb/401k/home
(2) Choose an employer account (in my case, I click "Mozilla")
This takes me to a dashboard with some header-tabs near the top, saying Summary | Contributions | Investments
etc.
(3) Right-click the "Summary" text on that header-tab section of the page (to give it focus without actually activating its link)
ACTUAL RESULTS:
There's a few-pixel layout adjustment in that whole header-tab area -- it all gets a little shorter or shifts upwards, which means all of the other header-tabs ("Contributions | Investments", etc) shift upwards a bit.
EXPECTED RESULTS:
No such layout adjustment; the container shouldn't change size and the other tabs shouldn't move.
Chrome dev-edition 96 gives EXPECTED RESULTS; Firefox Nightly 95 gives ACTUAL RESULTS
At Fidelity's website, tTis is because of a :focus
-triggered CSS rule which adjusts the padding
on the "Summary" link; and the link happens to have vertical-align:middle
, so this :focus
styling ends up triggering a version of this bug and changing the size of the container.
(Similarly: in the testcases here, if you remove or change the padding on the vertical-align:middle
thing, then it changes the size of the container in Firefox, but not in Chrome.)
![]() |
||
Updated•2 years ago
|
Updated•1 year ago
|
Description
•