Ah, so this probably depends on what the *other* actual font is here -- what font we're using for the non-ahem part of the test. That's probably what's different between my system and your system. If I add `<body style=font-family: fantasy>`, then I do see something like your screenshot. I see something even more severe if I add `font-family: Garuda`. But I see that if I make the same change in Chrome as well. And indeed, that behavior does seem to be `<!DOCTYPE html>`-dependent. So I think you're just seeing a case where your system happens to use a font with a lower-than-usual baseline. To the extent that this is causing trouble in WPTs, we should probably either use `vertical-align:top` to remove block-level baseline alignment from coming into play, or just set the Ahem font-family at a higher level so that we're not baseline-aligning Ahem into a line with an arbitrary-unknown-system-dependent font.
Bug 1866828 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Ah, so this probably depends on what the *other* actual font is here -- what font we're using for the non-ahem part of the test. That's probably what's different between my system and your system. If I add `<body style=font-family: fantasy>`, then I do see something like your screenshot. I see something even more severe if I add `font-family: Garuda`. But I see that if I make the same change in Chrome as well (for `Garuda` at least). And indeed, that behavior does seem to be `<!DOCTYPE html>`-dependent. So I think you're just seeing a case where your system happens to use a font with a lower-than-usual baseline. To the extent that this is causing trouble in WPTs, we should probably either use `vertical-align:top` to remove block-level baseline alignment from coming into play, or just set the Ahem font-family at a higher level so that we're not baseline-aligning Ahem into a line with an arbitrary-unknown-system-dependent font.