[css-grid] "inline-grid" containing items using the "Ahem" font and a "<!DOCTYPE html>" tag is misaligned.
Categories
(Core :: Layout: Grid, defect, P2)
Tracking
()
People
(Reporter: tlouw, Unassigned)
Details
Attachments
(4 files)
using "inline-grid"
When a page is using the "<!DOCTYPE html>" tag and uses the "inline-grid" to test items in a grid container instead of "grid" (which doesn't have this issue), then the alignment of items are off by usually 1px.
|
||
Comment 1•2 years ago
|
||
Could you post a testcase or a link to a WPT that suffers from this?
|
Reporter | |
Comment 2•2 years ago
|
||
The original issue comes from testing/web-platform/tests/css/css-grid/alignment/self-baseline/grid-self-baseline-changes-grid-area-size-004.html, but here is a simplified example.
|
|
||
Comment 3•2 years ago
•
|
||
Hmm, comment 2's attachment renders the same for me in Firefox and Chrome (on Ubuntu 22.04), with a single red square at the upper left of a green square. I verified that I am indeed getting the Ahem font there, too, in the DevTools "fonts" panel (actually using my system installed copy of Ahem, it looks like -- the relative-path stylesheet reference doesn't work in the bugzilla-hosted attachment here, but that's not needed anyway if you have Ahem installed as a local font)
Maybe there's some system-specific dependency here? (Do you have HiDPI or anything else that might be causing something interesting?)
|
|
Reporter | |
Comment 4•2 years ago
|
||
This is the rendering on my machine with everything "scaling related" i can think off turned off. Still a single pixel green line above the red box. Even if I zoom in that line stays there.
|
|
Reporter | |
Comment 5•2 years ago
|
||
I also tried the example in the Epiphany browser on gnome (running on manjaro, 2 day old clean install) and see the same 1 line pixel issue.
|
|
||
Comment 6•2 years ago
•
|
||
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.
|
||
Comment 7•2 years ago
|
||
We discussed this last week in #layout in matrix, and I came to the same conclusion that this is about the font in the <body> and this being a test issue.
|
|
Reporter | |
Comment 8•2 years ago
|
||
Adding vertical-align: top to body doesn't fix the issue. Wrapping both .grid and .block doesn't fix it either. Setting .grid to also have position: absolute, like .block does, solves it. That also avoid using baseline alignment between .block and .grid?
I also don't understand how the body font plays a role exactly. I mean both .block and .grid are using the Ahem font and should have the same baseline? Also .block is position: absolute, should that still make the two have to baseline align in body?
As a small sample, there are 12 of these tests in the same series, but only 004 and 005 have this issue.
|
|
||
Comment 9•2 years ago
|
||
Could you try setting the Ahem font-family on a higher up ancestor? I think that fixed it when I was testing similar things locally.
(The point is to remove the influence of the unknown local font, and setting Ahem higher up is one way to do that.)
|
|
||
Comment 10•2 years ago
•
|
||
Ah, also:
(In reply to Tiaan Louw from comment #8)
Adding
vertical-align: topto body doesn't fix the issue.
Sorry, the suggestion/workaround there would in fact be adding vertical-align:top to .grid, not to the body. That works for me locally, when I apply font-family:garuda on the body to push down the baseline (to trigger what-I-think-is-the-same-issue locally, since I don't see the issue on my machine by default)
I also don't understand how the body font plays a role exactly.
I mean both .block and .grid are using the Ahem font and should have the same baseline?
So .block styling is mostly-irrelevant here; it's abspos so it doesn't participate in inline layout or baseline-alignment. So its y-position isn't influenced by its own font or by the body's font; and .block also doesn't influence the y-position of our grid.
What's going on here is something like this:
- The body (like any
display:blockelement) will generate line-boxes that are sized based on its own font metrics. - If you place an inline-level child (in this case our
inline-grid) into the body, then that causes a line-box to be created in the body to contain that child, and the child gets baseline-aligned into that line-box (due to the child's defaultvertical-align:baseline). - If the body's font happens to generate line-boxes that are particularly large or with a particularly far-down-the-page baseline (as compared to the child's font), then that means the child will be shifted down in order to align its baseline with the baseline of the line-box that it's participating in.
- You can avoid this by: either (1) giving the inline-level thing (
.grid)vertical-align:topto opt it out of baseline-alignment in its line-box, if that's not something that the test is actually trying to test. This makes it snap to the top of its line-box, which puts it at the position we want it to be. - Or you can give the
body(the containing-block of the inline-level thing) the same font as the inline-level thing, so that the line-box will be the right size so that baseline-alignment-in-the-line-box won't introduce any sort of vertical shift.
Does that make some sense?
|
|
||
Comment 11•2 years ago
•
|
||
Here's a reduced testcase to help illustrate what's going on here:
data:text/html,<!DOCTYPE html>
<div style="font-size: 60px; border: 1px solid black">
<span style="font-size:16px; background: orange">Text</span>
The outer div here is similar to the body in your attached testcase; it has a font that happens to be larger than the child's font (explicitly so due to a difference in font-size, in this reduced testcase. In the WPTs and in your testcase, the font-size is presumably the same and the difference is not as severe; the line-box sizing mismatch just dependent on the metrics of the browser's chosen default font, as compared to Ahem).
The inner span here is similar to the inline-grid in your attached testcase; it's an inline-level element with a relatively smaller font (though really the distance-from-the-top-to-the-baseline is what matters).
This results in the span being shifted down by some arbitrary-ish amount in order to snap its baseline to the baseline of the line-box that it participates in. We can avoid that shift by giving it and its container the same font styling, or by giving the span vertical-align:top to opt out of baseline alignment within its line-box.
|
|
||
Comment 12•2 years ago
|
||
So I think this bug is essentially INVALID (there's no browser bug to fix here).
We should absolutely fix up the WPTs that are tripping over this (i.e. fix the test bugs where the tests are inadvertently depending on the system default font having the same-sized line-box as Ahem, when they place an inline-level Ahem element into a line-box with the default font). You could morph this bug into a fix-the-tests bug if you like, or you could land that patch on a separate fresh bug, or just as a supporting patch in your main grid-baseline bug.
(I'll leave it up to you whether you want to close this vs. morph it vs. do something else.)
|
|
Reporter | |
Comment 13•2 years ago
|
||
I fixed the tests in the patch for bug 1609403 by setting the grid's as vertical-align: top. I will close this as INVALID.
Description
•