[css-inline-3] vertical-align syntax / canonical ordering

[fantasai]

Minor syntactic questions on vertical-align now that it's a multi-valued shorthand:

• Should we allow the auto value of baseline-source in the shorthand?
  It's not clear what it refers to, is not useful (it's the default behavior), and is left out of serialization anyway... and if at some point we have some longhand that has a meaningful auto value, it would prevent being able to specify that. So I've a slight preference to keep it out of the shorthand.

• What's the best canonical ordering of the values?
  Seems like baseline-source should go first since English has that preference built into its grammar, but is there a preferred order for alignment-baseline vs. baseline-shift? (I'm leaning towards making alignment-baseline go first.)

• css-align restricts the position of first | last to right before the baseline keyword. Should we similarly restrict it in vertical-align? Or let it be reordered since it's parseable either way?

[css-meeting-bot]

The CSS Working Group just discussed [css-inline-3] vertical-align syntax / canonical ordering, and agreed to the following:

• RESOLVED: Canonical is first, alphabetic, shift
• RESOLVED: We want to allow reordering of values for vertical-align
• RESOLVED: In order to keep vertical-align and align similar we want to allow reordering of values for align property
• RESOLVED: auto value of baseline-source not allowed in vertical-align shorthand

The full IRC log of that discussion

Topic: [css-inline-3] vertical-align syntax / canonical ordering
github: https://github.com//issues/5235
fantasai: Minor questions. We split vert align to 2 longhands b/c SVG had the two longhands and CSS had shorthand
fantasai: Questions. Added baseline-srource long hand where it's first or last. What's best canonical ordering of values?
fantasai: I put baseline-source than baseline-alignment then baseline-shift. So first, alpha, 0.5em
fantasai: If that seems fine we can close on that
Rossen_: Thoughts?
vertical-align: first alphabetic 0.4em
Rossen_: Sounds like your proposal makes sense
heycam: Reads nicely in that order. Don't remember specific needs for these properties.
fantasai: Second question was normally we allow reorder of keywords and values as long as can parse w/o ambig. CSS align restricts position of first and last with baseline keyword.
fantasai: Do we want to be consistent with css align or do we want to allow reorder b/c in this context can parse either way
fantasai: I guess 3rd is make it reorderable in alignment
https://drafts.csswg.org/css-align-3/#baseline-values
heycam: In other properties is that also 2 sep properties or is it within the one?
fantasai: Current alignment prop is just one with no long hand. Current is first | last ? base-align
css-align - = [ first | last ]? baseline
fantasai: Do we match, allow arbitrary order in these, or loosen alignment to allow reorder
Rossen_: Can we do that?
fantasai: I think so. WOuld make invalid things valid. I don't think lots of people use first | last esp. since doesn't work in Chrome
Rossen_: Not sure I would jump to that conclusion so quickly. DOesn't sound benign
AmeliaBR: Change is to allow keyword to be in either order. Not breaking anything but something that didn't work might work
fantasai: Yes
AmeliaBR: Fairly new prop so I don't think big web compat risk
Rossen_: Data or feelings?
AmeliaBR: Feelings. And we warn people about zombie css and do not guar that something with no effect before is always no effect
fantasai: And first | last don't work in chrome so no reason to try and use it there
Rossen_: We have cononical ordering. Do we allow value reordering and do we expand to align. That's the progression. Let's decide vertical-align first.
fantasai: Preference is lean toward consistent.
Rossen_: If align wasn't there is there a reason to disallow reordering
fantasai: No
Rossen_: So for vertical-align want to allow reordering
Rossen_: We can resolve on this and then figure out if we can extend to align. Sounds like we feel fine without data but this is new and ideally doesn't break
Rossen_: With that have 2 resolutions
Rossen_: Anyone think we should go the other way? Keep them strict w/o re-ordering?
Rossen_: 2 resolutions.
Rossen_: The canonical order, vertical-align: first alphabetic 0.4em...record that?
Rossen_: Okay. Canonical is first, alphabetic, shift
florian: As spec currently?
fantasai: Yeah
Rossen_: Objections?
RESOLVED: Canonical is first, alphabetic, shift
Rossen_: We want to allow reordering of values for vertical-align
Rossen_: Objections?
RESOLVED: We want to allow reordering of values for vertical-align
Rossen_: Third: In order to keep vertical-align and align similar we want to allow reordering of values for align property
Rossen_: Objections?
RESOLVED: In order to keep vertical-align and align similar we want to allow reordering of values for align property
fantasai: One more on this. Normally when have longhand/shorthand we allow all values of longhand to be part of shorthand
fantasai: Initial value of baseline-source is auto. Do we want that intial value to be spec in vertical-align shorthand. It is initial value so no need to be specifiable. If it is explicitly and we add auto to alignment-baseline that's not parsable easily
fantasai: Might be a reason to disallow. Don't lose capability and opens possibility to open and auto value
florian: So when you mean auto you omit the value
fantasai: Yes
fantasai: I don't think it's a big deal. I have a slight preference to omit in case it's useful in future since auto is general keyword
florian: Easier to add than remove so let's do what you suggest and we can add it back if we change our mind
Rossen_: Fair. Other reasons to keep it by anyone?
that sounds good to me
Rossen_: Objections?
RESOLVED: auto value of baseline-source not allowed in vertical-align shorthand

[MatsPalmgren]

@fantasai

[css-align-3] Allow reordering of first|last vs baseline keywords.

Doesn't that make place-items: baseline last baseline ambiguous?