Bugzilla

(In reply to Brad Werth [:bradwerth] from comment #17)
I think the reference case is wrong there, and it's also a bit hard to reason about the testcase since (at least on my system) the flex container is only about as wide as two lines of text.  If you make the flex container a bit wider, as I just suggested in phab, then it's easier to visualize & reason about what's happening.

Here's what I see:
 (1) the yellow item is and orange items are aligning their last-baselines with each other
 (2) collectively, those two items are snapped to the right side (the cross-end side) of the flex container.
This results in the yellow item looking like it's offset by 1 line from the right edge of the flex container.

That is what the code currently intend to do, I believe, and I think it's correct, modulo my "However" below (which is outside the scope of this bug).

However, in fact it seems (2) may be incorrect per spec there.... at one point, I'm pretty sure "baseline" was specced as falling back to `flex-start` and (either explicitly or implicitly) last-baseline fell back to `flex-end`, and that's what we currently aim to do.  But now the [spec says they fall back to `start` and `end`](https://drafts.csswg.org/css-align/#valdef-justify-self-first-baseline) which means they're technically not supposed to care about the `wrap-reverse` cross-axis reversal here.  So I think per spec, the group of last-baseline aligned things are always supposed to be aligned to the flex container's block-end side (the left side in this case).  Having said that, that's not what we do or what Chrome does, so there may be some webcompat risk from making that change.  In any case, that change would be outside the scope of this bug.

(In reply to Brad Werth [:bradwerth] from comment #17)
I think the reference case is wrong there, and it's also a bit hard to reason about the testcase since (at least on my system) the flex container is only about as wide as two lines of text.  If you make the flex container a bit wider, as I just suggested in phab, then it's easier to visualize & reason about what's happening.

Here's what I see:
 (1) the yellow and orange items are aligning their last-baselines with each other
 (2) collectively, those two items are snapped to the right side (the cross-end side) of the flex container.
This results in the yellow item looking like it's offset by 1 line from the right edge of the flex container.

That is what the code currently intend to do, I believe, and I think it's correct, modulo my "However" below (which is outside the scope of this bug).

However, in fact it seems (2) may be incorrect per spec there.... at one point, I'm pretty sure "baseline" was specced as falling back to `flex-start` and (either explicitly or implicitly) last-baseline fell back to `flex-end`, and that's what we currently aim to do.  But now the [spec says they fall back to `start` and `end`](https://drafts.csswg.org/css-align/#valdef-justify-self-first-baseline) which means they're technically not supposed to care about the `wrap-reverse` cross-axis reversal here.  So I think per spec, the group of last-baseline aligned things are always supposed to be aligned to the flex container's block-end side (the left side in this case).  Having said that, that's not what we do or what Chrome does, so there may be some webcompat risk from making that change.  In any case, that change would be outside the scope of this bug.