Please, @tabatkins @fantasai could you take a look at this issue ? Not that it's specially urgent, but I m afraid it gets lost, since it's not even tagged yet. Thanks.

yes, Firefox's behavior is correct. See https://drafts.csswg.org/css-align-3/#baseline-values particularly the second-to-last note.

Flexbox's definitions of these properties are limited to the subset of features that were defined when it hit CR, so it can't include the first/last keywords. Think of Flexbox's alignment chapter as being an earlier Level of Box Alignment. :)

Let me know if you think a spec fix is needed here.

@javifernandez ?

@fantasai FYI, the draft css-flexbox spec still defines these properties differently than css-align.
https://drafts.csswg.org/css-flexbox/#justify-content-property

That seems like a spec bug to me. I think 8.2/8.3/8.4 in the draft css-flexbox spec needs to be removed/merged into css-align. It's confusing for everyone to have definitions for these properties in two places. (It's fine if the TR still have them with the old syntax/values, because everyone knows that TR means it's likely already obsolete.)

The ED is intended to be a temporary staging area for /TR; /TR is out-of-date mainly because it takes so long to get it updated. We're getting better at that now that W3C finally has tooling for pushing updates without involving handoffs among the editors and at least two members of W3C Staff, so differences between ED and /TR are really bugs in the process, and should be increasingly temporary.

I added a section to Module Interactions in Flexbox; there's already one in Align. And the Alignment section of Flexbox already says that it's will be superceded by Box Alignment. Not sure what else to do.

Also wrt this issue, CSS values always serialize to their shortest representation (unless that representation is newer than the longer representation, but that's not the case here).