Bugzilla

There are two sections in the WPT test where we render the testcase with different layout from the reference case:
* Section (1): the `123xxx` section (note, `123` renders as Ahem square-blocks) -- that section renders with a different height in the testcase vs. reference case.  That reduces to testcase 1. (The first div is analogous to the WPT reference case, the second slightly-shorter div is analogous to the WPT testcase).

* Section (2): the final section with `<span class="square"`>`, where the test is comparing a shrinkwrapped `1em`-tall inline element, in a div with the `size-adjust:50%` Ahem-backed font (testcase) vs. the equivalent setup without `size-adjust` (reference case).  That reduces to testcase 2.  (The bottom-left div is analogous to the reference case, and the bottom-center div is analogous to the testcase.)  Interestingly, in testcase 2, Chrome agrees with us on the sizing/positioning with `vertical-align:baseline` (top left & top center).

Anyway: as far as I can tell, section (1) is has an unstated/unjustified expectation that `Ahem`'s `line-height:normal` must be no-greater-than the same-font-size `sans-serif` font's line-height.  (If that holds, then there's no room for the `size-adjust` to reduce the line height there, because the sans-serif text is "propping it up".)

And section (2) has an unstated/unjustified expectation that `Ahem`'s ``line-height:normal` must be exactly 1em.  (If that holds, then the tallest `<span class="square">` child will be flush with the top of the block there, in both the testcase and the reference case.  But: in browsers where the `normal` line-height is taller than 1em, the testcase may have that line being somewhat taller in the reference case vs. the testcase, with the square being bottom-aligned in whatever height the line ends up.)

I'm not yet sure what the best workaround is for (1); working on that...
But we can fix (2) by specifying `line-height:1` on the container in the reference case.

There are two sections in the WPT test where we render the testcase with different layout from the reference case:
* Section (1): the `123xxx` section (note, `123` renders as Ahem square-blocks) -- that section renders with a different height in the testcase vs. reference case.  That reduces to testcase 1. (The first div is analogous to the WPT reference case, the second slightly-shorter div is analogous to the WPT testcase).

* Section (2): the final section with `<span class="square">`, where the test is comparing a shrinkwrapped `1em`-tall inline element, in a div with the `size-adjust:50%` Ahem-backed font (testcase) vs. the equivalent setup without `size-adjust` (reference case).  That reduces to testcase 2.  (The bottom-left div is analogous to the reference case, and the bottom-center div is analogous to the testcase.)  Interestingly, in testcase 2, Chrome agrees with us on the sizing/positioning with `vertical-align:baseline` (top left & top center).

Anyway: as far as I can tell, section (1) is has an unstated/unjustified expectation that `Ahem`'s `line-height:normal` must be no-greater-than the same-font-size `sans-serif` font's line-height.  (If that holds, then there's no room for the `size-adjust` to reduce the line height there, because the sans-serif text is "propping it up".)

And section (2) has an unstated/unjustified expectation that `Ahem`'s ``line-height:normal` must be exactly 1em.  (If that holds, then the tallest `<span class="square">` child will be flush with the top of the block there, in both the testcase and the reference case.  But: in browsers where the `normal` line-height is taller than 1em, the testcase may have that line being somewhat taller in the reference case vs. the testcase, with the square being bottom-aligned in whatever height the line ends up.)

I'm not yet sure what the best workaround is for (1); working on that...
But we can fix (2) by specifying `line-height:1` on the container in the reference case.