Open Bug 1436801 Opened 6 years ago Updated 1 year ago

Vertical padding influences baseline alignment of text around span with "vertical-align:middle" (only in Firefox)

Categories

(Core :: Layout: Block and Inline, defect, P3)

57 Branch
defect

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
Component: Layout: Text → Layout: Block and Inline
Attached file testcase 1
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")
[ Triage 2017/02/20: P3 ]
Priority: -- → P3

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Webcompat Priority: --- → ?

See bug 1547409. Migrating whiteboard priority tags to program flags.

Webcompat Priority: ? → revisit
See Also: → 1563715

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.)

Webcompat Priority: revisit → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.