They're definitely not baseline-shift values, either, they're not shifting relative to another alignment.

But syntactically, the important question is how they combine. Does it make sense to align and then shift?

E.g., vertical-align: text-bottom -2px has a meaning (align based on the text-bottom position, then shift by down by 2px). I think that vertical-align: top -2px makes sense, although I'm not sure if it would create layout loops. But what would vertical-align: text-bottom top mean?

I agree that these aren't a perfect fit for alignment-baseline, since they don't use baselines at all, they use line boxes. If it doesn't make sense to add a baseline shift in addition to one of these alignments, maybe they could be a separate set of values for vertical-align that replace the baseline-based alignments altogether? E.g., the syntax for vertical-align would be [<'baseline-source'> || <'baseline-shift'> || <'alignment-baseline'>] | <line-box-alignment>, where a line-box alignment keyword makes the others irrelevant.

E.g., the syntax for vertical-align would be [<'baseline-source'> || <'baseline-shift'> || <'alignment-baseline'>] | , where a line-box alignment keyword makes the others irrelevant.

Happy to make that change, too. :) But regardless, it has to be stored in a longhand. I'd rather just add it to baseline-shift than create another longhand.

But what would vertical-align: text-bottom top mean?

It asks for top alignment within the container (line box in the case of an inline-level element, table row in the case of table cells) and sets the alignment baseline to the text-bottom baseline. If the row has no 'baseline'-aligned cells, then this is the alignment baseline that will get exported as the table row’s baseline. It's a weird thing to ask, but it has a meaning.

The CSS Working Group just discussed [css-inline-3] Shift top | bottom | center values from alignment-baseline to baseline-shift, and agreed to the following:

• RESOLVED: accept change as proposed by fantasai unless strong impl argument

For the spec prose, I'd suggest describing these as “shifting to” values as opposed to “shifting by” values. Whatever the initial alignment would be, you then shift until tops/bottoms/centers match.

@AmeliaBR rewrote intro paragraph as

This property specifies the box’s post-alignment shift. The baseline-relative values , sub, super shift the box relative to its baseline-aligned position, whereas the line-relative values top, center, and bottom shift the inline box and its contents relative to the bounds of its line box.

I'm not convinced the section overall reads that great, there's a ton of visual noise in that paragraph as a result of marking up terms/code/etc. Let me know if you have any suggestions for making it better. :)

I'm thinking that it might be better for the note that's at a7b0a94#diff-81193009bbd77efc16db63e0098a69baR665 to be moved to 4.2.3, between the first paragraph and the advisement.

@frivoal middle is not a baseline-shift value, but an alignment-baseline value.

Ah, right. Then probably the note should read:

[…]
and ''vertical-align/center''''vertical-align/middle'' (''alignment-baseline: middle'') to ''align-content/center''.
[...]

If not, which part of the spec (other than that note) says that vertical-align: center maps to alignment-baseline: middle?

@frivoal :/ Fixed. Thanks. :)

There's some follow-up nonsense wrt table cells in #5234, but calling this fixed.