The main issue here is that we're aligning within the grid's padding-box (or rather, we're aligning within a **box that's the size of the grid's padding-box** -- but then we use the result as an offset within the grid's content-box). We're using the padding-box for this because the spec used to say so, as quoted in bug 1269017 comment 0 (`The static position [CSS21] of an absolutely-positioned child of a grid container is determined as if it were the sole grid item in a grid area whose edges coincide with the padding edges of the grid container.`) The relevant spec text now says to use the *content edges* of the grid container, though: https://drafts.csswg.org/css-align/#staticpos-rect https://drafts.csswg.org/css-grid/#static-position Note that for abspos content *for whom the grid container also forms the abspos containing block*, we do still use the padding edges by default, as laid out in grid section 10.1 (`an auto value for a grid-placement property contributes a special line to the placement whose position is that of the corresponding padding edge of the grid container). So the padding-box is still the relevant alignment container for those cases. But IIRC, the grid container is not the abspos containing block in any of the WPT tests that are failing here.
Bug 1707643 Comment 4 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The main issue here is that we're aligning within the grid's padding-box (or rather, we're aligning within a **box that's the size of the grid's padding-box** -- but then we use the result as an offset within the grid's content-box). We're using the padding-box for this because the spec used to say so, as quoted in bug 1269017 comment 0 (`The static position [CSS21] of an absolutely-positioned child of a grid container is determined as if it were the sole grid item in a grid area whose edges coincide with the padding edges of the grid container.`) The relevant spec text now says to use the *content edges* of the grid container, though: https://drafts.csswg.org/css-align/#staticpos-rect https://drafts.csswg.org/css-grid/#static-position One exception is for abspos content *for whom the grid container also forms the abspos containing block*, we do still use the padding edges by default, as laid out in grid section 10.1 (`an auto value for a grid-placement property contributes a special line to the placement whose position is that of the corresponding padding edge of the grid container). So the padding-box is still the relevant alignment container for those cases. But IIRC, the grid container is not the abspos containing block in any of the WPT tests that are failing here.
The main issue here is that we're aligning within the grid's padding-box (or rather, we're aligning within a **box that's the size of the grid's padding-box** -- but then we use the result as an offset within the grid's content-box). We're using the padding-box for this because the spec used to say so, as quoted in bug 1269017 comment 0 (`The static position [CSS21] of an absolutely-positioned child of a grid container is determined as if it were the sole grid item in a grid area whose edges coincide with the padding edges of the grid container.`) The relevant spec text now says to use the *content edges* of the grid container, though: https://drafts.csswg.org/css-align/#staticpos-rect https://drafts.csswg.org/css-grid/#static-position One exception is for abspos content *for whom the grid container also forms the abspos containing block* -- in that case, we are still supposed to use the padding edges by default, as laid out in grid section 10.1 (`an auto value for a grid-placement property contributes a special line to the placement whose position is that of the corresponding padding edge of the grid container). So the padding-box is still the relevant alignment container for those cases. But IIRC, the grid container is not the abspos containing block in any of the WPT tests that are failing here.
The main issue here is that we're aligning within the grid's padding-box (or rather, we're aligning within a **box that's the size of the grid's padding-box** -- but then we use the result as an offset within the grid's content-box). We're using the padding-box for this because the spec used to say so, as quoted in bug 1269017 comment 0 (`The static position [CSS21] of an absolutely-positioned child of a grid container is determined as if it were the sole grid item in a grid area whose edges coincide with the padding edges of the grid container.`) The relevant spec text now says to use the *content edges* of the grid container, though: https://drafts.csswg.org/css-align/#staticpos-rect https://drafts.csswg.org/css-grid/#static-position One exception is for abspos content *for whom the grid container also forms the abspos containing block* -- in that case, we are still supposed to use the padding edges by default, as laid out in grid section 10.1 (`an auto value for a grid-placement property contributes a special line to the placement whose position is that of the corresponding padding edge of the grid container`). So the padding-box is still the relevant alignment container for those cases. But IIRC, the grid container is not the abspos containing block in any of the WPT tests that are failing here.
The main issue here is that we're aligning within the grid's padding-box (or rather, we're aligning within a **box that's the size of the grid's padding-box** -- but then we use the result as an offset within the grid's content-box). We're using the padding-box for this because the spec used to say so, as quoted in bug 1269017 comment 0 (*The static position [CSS21] of an absolutely-positioned child of a grid container is determined as if it were the sole grid item in a grid area whose edges coincide with the **padding edges** of the grid container.*) The relevant spec text now says to use the *content edges* of the grid container, though: https://drafts.csswg.org/css-align/#staticpos-rect https://drafts.csswg.org/css-grid/#static-position One exception is for abspos content *for whom the grid container also forms the abspos containing block* -- in that case, we are still supposed to use the padding edges by default, as laid out in grid section 10.1 (*an auto value for a grid-placement property contributes a special line to the placement whose position is that of the corresponding **padding edge** of the grid container*). So the padding-box is still the relevant alignment container for those cases. But IIRC, the grid container is not the abspos containing block in any of the WPT tests that are failing here.
The main issue here is that we're aligning within the grid's padding-box (or rather, we're aligning within a **box that's the size of the grid's padding-box** -- but then we use the result as an offset within the grid's content-box). We're using the padding-box for this because the spec used to say so, as quoted in bug 1269017 comment 0 (*The static position [CSS21] of an absolutely-positioned child of a grid container is determined as if it were the sole grid item in a grid area whose edges coincide with the **padding edges** of the grid container.*) The relevant spec text now says to use the *content edges* of the grid container, though: https://drafts.csswg.org/css-align/#staticpos-rect https://drafts.csswg.org/css-grid/#static-position One exception is for abspos content *for whom the grid container also forms the abspos containing block* -- in that case, we are still supposed to use the padding edges by default, as laid out in grid section 10.1 (*an auto value for a grid-placement property contributes a special line to the placement whose position is that of the corresponding **padding edge** of the grid container*). So the padding-box is still the relevant alignment container for those cases. But IIRC, that's not relevant to the WPT tests that are failing here; the grid container is not the abspos containing block in any of those tests.