Abspos flex children in a row-reverse/column-reverse/wrap-reverse container need to be aligned to end (flex-start) side
Categories
(Core :: Layout: Flexbox, defect, P3)
Tracking
()
People
(Reporter: dholbert, Assigned: TYLin)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [wpt-triaged], [wptsync upstream])
Attachments
(3 files)
Right now we fail a few subtests in these WPT tests:
https://wpt.fyi/results/css/css-flexbox/position-absolute-001.html
https://wpt.fyi/results/css/css-flexbox/position-absolute-002.html
The issues are all for cases where there's a flex container with a reversed main axis or cross axis (from flex-direction: row-reverse
or column-reverse
, or flex-wrap: wrap-reverse
).
The test asserts that the static position of an abspos child should be at the "end" side of the flex container (the flex-start
side, since the relevant flex axis is reversed with a *-reverse
keyword in these cases).
We incorrectly place the abspos child at the start
side. But we're wrong -- the relevant behavior here is the "normal" behavior (since "normal" is the default align
/justify
keyword), and the spec says:
normal Behavior
For replaced absolutely-positioned boxes,
the 'normal' keyword behaves as 'start'.For all other absolutely-positioned boxes, 'normal' behaves as 'stretch'
https://drafts.csswg.org/css-align/#align-abspos
The last line is the relevant one here -- normal
is supposed to behave as stretch
, and stretch
"falls back to flex-start generally", which in this flex-axis-reversed scenario would mean the far/"end" side of the flex container.
Testcase attached -- currently we do the right thing for flex-start
(the lime rect) but not for stretch
or for the default behavior (the red and orange rects).
Updated•6 years ago
|
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Comment 2•3 years ago
|
||
The WPT tests have moved to a subdirectory:
https://wpt.fyi/results/css/css-flexbox/abspos/position-absolute-001.html
https://wpt.fyi/results/css/css-flexbox/abspos/position-absolute-002.html
Assignee | ||
Comment 3•3 years ago
|
||
In Flexbox spec 4.1, Example 3 [1]:
... since the absolutely-positioned box is considered to be
"fixed-size", a value of stretch is treated the same as flex-start.
Also, per Alignment 3 spec [2]:
The default fallback alignment for 'stretch' is 'flex-start'.
Thus, when computing the alignment for flexbox's abspos children in
CSSAlignmentForAbsPosChild(), we convert 'stretch' to 'flex-start', and let the
subsequent logic convert 'flex-start' to either 'start' or 'end', because
nsAbsoluteContainingBlock don't know how to deal with the flex-relative axis.
This patch makes us behave the same as Google Chrome on the modified testcases.
[1] https://drafts.csswg.org/css-flexbox/#abspos-items
[2] https://drafts.csswg.org/css-align/#valdef-align-content-stretch
Updated•3 years ago
|
Assignee | ||
Comment 4•3 years ago
|
||
Per Alignment spec [1], the default fallback alignment for 'space-between' is
'flex-start'.
[1] https://drafts.csswg.org/css-align/#valdef-align-content-space-between
Depends on D134543
Reporter | ||
Comment 6•3 years ago
|
||
Thanks for taking this and for updating the test expectations!
Making sense of things: it looks like the default fallback value changed in the spec, in the time since this behavior was originally implemented. For space-between
, it changed here:
https://github.com/w3c/csswg-drafts/commit/36ca6ddf33fa4f2934c663a8c74eab0d59beaa69#diff-273c5b2266723c0e21f50eff93d04ae10a9a0ce8cc67825e68a64c74f4056073
...and I'm not about the history for stretch
(dug around a little bit but didn't immediately see where it had previously been specified as falling back to start
).
Reporter | ||
Comment 7•3 years ago
•
|
||
Aha -- for stretch
it looks like the specced fallback behavior changed here (the old spec text said Otherwise, this is equivalent to ''start''
):
https://github.com/w3c/csswg-drafts/commit/1e436030985a2adbc9b54b5aade1ff882c5ed85d#diff-0b7c7fab23fb5f18a5f7ae5a9ec43fc8e9e4f1ac5f8ee16a02cb7d1ae2360e95L218
Assignee | ||
Comment 8•3 years ago
|
||
Thanks for digging into the spec history!
Comment 11•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/ce9e6a8b981c
https://hg.mozilla.org/mozilla-central/rev/791f9fca748e
Updated•3 years ago
|
Description
•