[css-inline-3] vertical-align syntax / canonical ordering #5235
Labels
Milestone
Comments
fantasai
added a commit
that referenced
this issue
Jun 18, 2020
…'first baseline' just like the box alignment properties. #5235
|
The CSS Working Group just discussed
The full IRC log of that discussion<dael> Topic: [css-inline-3] vertical-align syntax / canonical ordering<dael> github: https://github.com//issues/5235 <dael> fantasai: Minor questions. We split vert align to 2 longhands b/c SVG had the two longhands and CSS had shorthand <dael> fantasai: Questions. Added baseline-srource long hand where it's first or last. What's best canonical ordering of values? <dael> fantasai: I put baseline-source than baseline-alignment then baseline-shift. So first, alpha, 0.5em <dael> fantasai: If that seems fine we can close on that <dael> Rossen_: Thoughts? <fantasai> vertical-align: first alphabetic 0.4em <dael> Rossen_: Sounds like your proposal makes sense <dael> heycam: Reads nicely in that order. Don't remember specific needs for these properties. <dael> 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. <dael> 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 <dael> fantasai: I guess 3rd is make it reorderable in alignment <fantasai> https://drafts.csswg.org/css-align-3/#baseline-values <dael> heycam: In other properties is that also 2 sep properties or is it within the one? <dael> fantasai: Current alignment prop is just one with no long hand. Current is first | last ? base-align <fantasai> css-align - <baseline-position> = [ first | last ]? baseline <dael> fantasai: Do we match, allow arbitrary order in these, or loosen alignment to allow reorder <dael> Rossen_: Can we do that? <dael> 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 <dael> Rossen_: Not sure I would jump to that conclusion so quickly. DOesn't sound benign <dael> AmeliaBR: Change is to allow keyword to be in either order. Not breaking anything but something that didn't work might work <dael> fantasai: Yes <dael> AmeliaBR: Fairly new prop so I don't think big web compat risk <dael> Rossen_: Data or feelings? <dael> AmeliaBR: Feelings. And we warn people about zombie css and do not guar that something with no effect before is always no effect <dael> fantasai: And first | last don't work in chrome so no reason to try and use it there <dael> 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. <dael> fantasai: Preference is lean toward consistent. <dael> Rossen_: If align wasn't there is there a reason to disallow reordering <dael> fantasai: No <dael> Rossen_: So for vertical-align want to allow reordering <dael> 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 <dael> Rossen_: With that have 2 resolutions <dael> Rossen_: Anyone think we should go the other way? Keep them strict w/o re-ordering? <dael> Rossen_: 2 resolutions. <dael> Rossen_: The canonical order, vertical-align: first alphabetic 0.4em...record that? <dael> Rossen_: Okay. Canonical is first, alphabetic, shift <dael> florian: As spec currently? <dael> fantasai: Yeah <dael> Rossen_: Objections? <dael> RESOLVED: Canonical is first, alphabetic, shift <dael> Rossen_: We want to allow reordering of values for vertical-align <dael> Rossen_: Objections? <dael> RESOLVED: We want to allow reordering of values for vertical-align <dael> Rossen_: Third: In order to keep vertical-align and align similar we want to allow reordering of values for align property <dael> Rossen_: Objections? <dael> RESOLVED: In order to keep vertical-align and align similar we want to allow reordering of values for align property <dael> fantasai: One more on this. Normally when have longhand/shorthand we allow all values of longhand to be part of shorthand <dael> 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 <dael> fantasai: Might be a reason to disallow. Don't lose capability and opens possibility to open and auto value <dael> florian: So when you mean auto you omit the value <dael> fantasai: Yes <dael> 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 <dael> florian: Easier to add than remove so let's do what you suggest and we can add it back if we change our mind <dael> Rossen_: Fair. Other reasons to keep it by anyone? <dbaron> that sounds good to me <dael> Rossen_: Objections? <dael> RESOLVED: auto value of baseline-source not allowed in vertical-align shorthand |
fantasai
added a commit
that referenced
this issue
Aug 13, 2020
fantasai
added a commit
that referenced
this issue
Aug 13, 2020
Doesn't that make |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Minor syntactic questions on vertical-align now that it's a multi-valued shorthand:
Should we allow the
autovalue ofbaseline-sourcein 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
autovalue, 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-sourceshould go first since English has that preference built into its grammar, but is there a preferred order foralignment-baselinevs.baseline-shift? (I'm leaning towards makingalignment-baselinego first.)css-align restricts the position of
first | lastto right before thebaselinekeyword. Should we similarly restrict it invertical-align? Or let it be reordered since it's parseable either way?The text was updated successfully, but these errors were encountered: