New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-align] Add shorthands for alignment properties #595

Closed
fantasai opened this Issue Oct 12, 2016 · 53 comments

Comments

Projects
None yet
@fantasai
Contributor

fantasai commented Oct 12, 2016

Can't find where this was originally filed, but there was a request to add shorthands for the alignment properties, e.g. align-items+justify-items = foo-items.

foo-items: <'align-items'> <'justify-items'>?
foo-self: <'align-self'> <'justify-self'>?
foo-content: <'align-content'> <'justify-content'>?

Name "foo"!

[Suggestions so far are "arrange" and "place".]

@keithjgrant

This comment has been minimized.

Show comment
Hide comment
@keithjgrant

keithjgrant Oct 12, 2016

Contributor

“compose” might be a viable option.

Contributor

keithjgrant commented Oct 12, 2016

“compose” might be a viable option.

@jensimmons

This comment has been minimized.

Show comment
Hide comment
@jensimmons

jensimmons Oct 12, 2016

I mentioned this on Twitter and Harry Roberts suggested distribute.
https://twitter.com/csswizardry/status/786249388687437824

jensimmons commented Oct 12, 2016

I mentioned this on Twitter and Harry Roberts suggested distribute.
https://twitter.com/csswizardry/status/786249388687437824

@achalv

This comment has been minimized.

Show comment
Hide comment
@achalv

achalv Oct 12, 2016

(Found this link to this issue through Jen's tweet, hope you don't mind me jumping in! :] )

+1 for "arrange"

achalv commented Oct 12, 2016

(Found this link to this issue through Jen's tweet, hope you don't mind me jumping in! :] )

+1 for "arrange"

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Oct 12, 2016

Without a separator like / between the two values, things like foo-items:center safe right are ambiguous.

MatsPalmgren commented Oct 12, 2016

Without a separator like / between the two values, things like foo-items:center safe right are ambiguous.

@jensimmons

This comment has been minimized.

Show comment
Hide comment
@jensimmons

jensimmons Oct 12, 2016

I feel like arrange could potentially be confusing because it's too close to align.

It's hard to remember which is which already:
justify-self
align-self
justify-items
align-items
justify-content
align-content
(and for a refresher, the values are things like space-between, space-around, start, end, center, etc.)

adding:
arrange-self
arrange-items
arrange-content
to that list seems confusing. hm.

I like distribute. I'm sure there are other good words, too.

And btw, the CSSWG welcomes feedback from everyone. From anyone who writes CSS. This is where the sausage gets made, and this decision is something you'll have to live with. So feel free chime in. Do think about all people who write CSS, and what would be good for them (not just your own personal feeling). Think about the fact many (most?) people who write CSS do not speak English. We want to pick words that will work globally.

jensimmons commented Oct 12, 2016

I feel like arrange could potentially be confusing because it's too close to align.

It's hard to remember which is which already:
justify-self
align-self
justify-items
align-items
justify-content
align-content
(and for a refresher, the values are things like space-between, space-around, start, end, center, etc.)

adding:
arrange-self
arrange-items
arrange-content
to that list seems confusing. hm.

I like distribute. I'm sure there are other good words, too.

And btw, the CSSWG welcomes feedback from everyone. From anyone who writes CSS. This is where the sausage gets made, and this decision is something you'll have to live with. So feel free chime in. Do think about all people who write CSS, and what would be good for them (not just your own personal feeling). Think about the fact many (most?) people who write CSS do not speak English. We want to pick words that will work globally.

@meyerweb

This comment has been minimized.

Show comment
Hide comment
@meyerweb

meyerweb Oct 12, 2016

I like distribute-items and distribute-content, but place-self makes more sense to me than distribute-self. Ditto on all counts even if distribute is replaced with arrange.

meyerweb commented Oct 12, 2016

I like distribute-items and distribute-content, but place-self makes more sense to me than distribute-self. Ditto on all counts even if distribute is replaced with arrange.

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Oct 12, 2016

+1 for "place" since it's short and encompass what all these properties do.
"arrange" seems more vague to me, it could mean "sort" or other ways of arranging.

I don't like "distribute" because only the *-content properties are about "distribution" (the *-self and *-items are about alignment, not distribution.) Also, it's too long. :-)
https://drafts.csswg.org/css-align-3/#content-distribution

MatsPalmgren commented Oct 12, 2016

+1 for "place" since it's short and encompass what all these properties do.
"arrange" seems more vague to me, it could mean "sort" or other ways of arranging.

I don't like "distribute" because only the *-content properties are about "distribution" (the *-self and *-items are about alignment, not distribution.) Also, it's too long. :-)
https://drafts.csswg.org/css-align-3/#content-distribution

@keithjgrant

This comment has been minimized.

Show comment
Hide comment
@keithjgrant

keithjgrant Oct 12, 2016

Contributor

I do agree w/ @jensimmons about these names getting confusing. It’s certainly worth considering whether the convenience of a shorthand is worth adding more very similar names to the mix.

Outside the box idea: Could align-* be extended to become the shorthand, supporting both the cross-axis and the main-axis values?

Contributor

keithjgrant commented Oct 12, 2016

I do agree w/ @jensimmons about these names getting confusing. It’s certainly worth considering whether the convenience of a shorthand is worth adding more very similar names to the mix.

Outside the box idea: Could align-* be extended to become the shorthand, supporting both the cross-axis and the main-axis values?

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Oct 12, 2016

That won't work so well for *-content because align-content:stretch end would be valid both as a single value and as a shorthand with two values. It would work if a separator is required though.

MatsPalmgren commented Oct 12, 2016

That won't work so well for *-content because align-content:stretch end would be valid both as a single value and as a shorthand with two values. It would work if a separator is required though.

@rchrdnsh

This comment has been minimized.

Show comment
Hide comment
@rchrdnsh

rchrdnsh Oct 12, 2016

kinda digging 'place' at the moment, over 'arrange' and 'distribute'. So, 'align-self: center' + 'justify-self: center' would = 'place-self: center'... or 'place-item: center', or 'place-content: center'

yeah, liking that one :-)

rchrdnsh commented Oct 12, 2016

kinda digging 'place' at the moment, over 'arrange' and 'distribute'. So, 'align-self: center' + 'justify-self: center' would = 'place-self: center'... or 'place-item: center', or 'place-content: center'

yeah, liking that one :-)

@Crissov

This comment has been minimized.

Show comment
Hide comment
@Crissov

Crissov Oct 12, 2016

  • spread-items, spread-self, spread-content
  • splay-items, splay-self, splay-content

Crissov commented Oct 12, 2016

  • spread-items, spread-self, spread-content
  • splay-items, splay-self, splay-content
@SebastianZ

This comment has been minimized.

Show comment
Hide comment
@SebastianZ

SebastianZ Oct 12, 2016

Contributor
  • spread-items, spread-self, spread-content
  • splay-items, splay-self, splay-content

spread-self and splay-self don't make sense to me (same for distribute-self). Also (as a non-native speaker) I've never heard the word splay so far.

'arrange' might be misspelled as 'arange' and, as @MatsPalmgren mentioned, it may also be misinterpreted.

So I vote for place-*.

The names {align,justify}-{items,content} are already bad choices. I always forget whether I need to use align-* or justify-* and whether to use *-items or *-content.

I'd love to see them bikeshedded, but unfortunately it's already too late to change them.

Sebastian

Contributor

SebastianZ commented Oct 12, 2016

  • spread-items, spread-self, spread-content
  • splay-items, splay-self, splay-content

spread-self and splay-self don't make sense to me (same for distribute-self). Also (as a non-native speaker) I've never heard the word splay so far.

'arrange' might be misspelled as 'arange' and, as @MatsPalmgren mentioned, it may also be misinterpreted.

So I vote for place-*.

The names {align,justify}-{items,content} are already bad choices. I always forget whether I need to use align-* or justify-* and whether to use *-items or *-content.

I'd love to see them bikeshedded, but unfortunately it's already too late to change them.

Sebastian

@liamquin

This comment has been minimized.

Show comment
Hide comment
@liamquin

liamquin Oct 12, 2016

On Wed, 2016-10-12 at 10:57 -0700, Jen Simmons wrote:

I feel like arrange could potentially be confusing because it's too
close to align.

It's hard to remember which is which already:
justify-self
align-self
justify-items
align-items
justify-content
align-content

Traditionally in graphic design i think we have,

  • distribute items - put even amounts of space between them
  • align items - line them up along a common axis in some way
  • justify items - distribute space between them so the edges align with
    two outer axes
  • position items - a pretentious way of saying put items into their
    assigned places

There are some other terms used in design and composition but I don't
think they are relevant here.

"arrange" is a more general term that subsumes all the ones I listed, I
think.

Liam

liamquin commented Oct 12, 2016

On Wed, 2016-10-12 at 10:57 -0700, Jen Simmons wrote:

I feel like arrange could potentially be confusing because it's too
close to align.

It's hard to remember which is which already:
justify-self
align-self
justify-items
align-items
justify-content
align-content

Traditionally in graphic design i think we have,

  • distribute items - put even amounts of space between them
  • align items - line them up along a common axis in some way
  • justify items - distribute space between them so the edges align with
    two outer axes
  • position items - a pretentious way of saying put items into their
    assigned places

There are some other terms used in design and composition but I don't
think they are relevant here.

"arrange" is a more general term that subsumes all the ones I listed, I
think.

Liam

@malyw

This comment has been minimized.

Show comment
Hide comment
@malyw

malyw Oct 12, 2016

+1 for the "place" shorthand prefix.
Short and reflects the purpose IMO.

I created a PostCSS plugin to try in my projects and see the real benefits of having such shorthands:
https://github.com/malyw/postcss-alignment-shorthands

For now, it uses "place" but is easily configurable to apply any other.

malyw commented Oct 12, 2016

+1 for the "place" shorthand prefix.
Short and reflects the purpose IMO.

I created a PostCSS plugin to try in my projects and see the real benefits of having such shorthands:
https://github.com/malyw/postcss-alignment-shorthands

For now, it uses "place" but is easily configurable to apply any other.

@danilovaz

This comment has been minimized.

Show comment
Hide comment
@danilovaz

danilovaz Oct 12, 2016

I'm a non-native speaker of English, I'm a Brazilian guy. So I agree that most of terms cited are confusing. This terms make the task of align items so confusing and frustrating.

I'm also agree with @malyw about the way him created shorthands to use with PostCSS. Here in Brazil, my friend @afonsopacifer has created something like that, because it we agree the terms are so confusing. So him created this: https://github.com/bananacss/bananacss

Of course, I know this have no sense to use terms like bnn when the focus is on globalize. But it's a way to move on and find the right choice. And when I tested this made much more sense for me than the way existing today.

For now, I agree with place. But it's not the perfect term, yet.

And I really don't know if I should opine something about it and I hope you will forgive me if this is not the right place. Anyway, as I use CSS in my day to day and as a non-native speaker, I wanted to contribute with my opinion 😄

danilovaz commented Oct 12, 2016

I'm a non-native speaker of English, I'm a Brazilian guy. So I agree that most of terms cited are confusing. This terms make the task of align items so confusing and frustrating.

I'm also agree with @malyw about the way him created shorthands to use with PostCSS. Here in Brazil, my friend @afonsopacifer has created something like that, because it we agree the terms are so confusing. So him created this: https://github.com/bananacss/bananacss

Of course, I know this have no sense to use terms like bnn when the focus is on globalize. But it's a way to move on and find the right choice. And when I tested this made much more sense for me than the way existing today.

For now, I agree with place. But it's not the perfect term, yet.

And I really don't know if I should opine something about it and I hope you will forgive me if this is not the right place. Anyway, as I use CSS in my day to day and as a non-native speaker, I wanted to contribute with my opinion 😄

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Oct 12, 2016

I tend to think these shorthands should have a separator other
than space. Otherwise, the following two snippets leads to
different results:

element.style.alignItems = A;
element.style.justifyItems = B;

vs.

element.style.placeItems = A + " " + B;

... when B starts with safe.

Same problem also occurs for placeContent with A="end" and
B="stretch end", etc.

MatsPalmgren commented Oct 12, 2016

I tend to think these shorthands should have a separator other
than space. Otherwise, the following two snippets leads to
different results:

element.style.alignItems = A;
element.style.justifyItems = B;

vs.

element.style.placeItems = A + " " + B;

... when B starts with safe.

Same problem also occurs for placeContent with A="end" and
B="stretch end", etc.

@dancork

This comment has been minimized.

Show comment
Hide comment
@dancork

dancork Oct 13, 2016

The only issue i see with place is that implies a physical action of putting each item. Align and justify are less tangible, and both currently related to type.

My vote would be for arrange or distribute.

dancork commented Oct 13, 2016

The only issue i see with place is that implies a physical action of putting each item. Align and justify are less tangible, and both currently related to type.

My vote would be for arrange or distribute.

@rachelandrew

This comment has been minimized.

Show comment
Hide comment
@rachelandrew

rachelandrew Oct 13, 2016

Contributor

I'd be happiest with either arrange or distribute, they both seem descriptive.

Contributor

rachelandrew commented Oct 13, 2016

I'd be happiest with either arrange or distribute, they both seem descriptive.

@SelenIT

This comment has been minimized.

Show comment
Hide comment
@SelenIT

SelenIT Oct 18, 2016

Collaborator

I like @keithjgrant's idea about extending align- to become the shorthand (rather than adding new keyword) very much. As one more option: what about something like align2d (kind of reusing the existing naming pattern for keywords like translate3d and, I hope, unambiguous enough for non-English-speaking people like me)?

Collaborator

SelenIT commented Oct 18, 2016

I like @keithjgrant's idea about extending align- to become the shorthand (rather than adding new keyword) very much. As one more option: what about something like align2d (kind of reusing the existing naming pattern for keywords like translate3d and, I hope, unambiguous enough for non-English-speaking people like me)?

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Oct 26, 2016

@dbaron tells me that having a shorthand and longhand with the same name is impossible to implement in Gecko. So that excludes align as the prefix.

It appears that arrange and place are the two most popular prefixes, and I believe the separator must be something else than space (see my comments above), I suggest '/'.
So to write them out, we have:

arrange-items: <align-items> / <justify-items>
arrange-self: <align-self> / <justify-self>
arrange-content: <align-content> / <justify-content>

or

place-items: <align-items> / <justify-items>
place-self: <align-self> / <justify-self>
place-content: <align-content> / <justify-content>

(other prefixes suggested: compose distribute spread splay position align2d)

The voting tally for these two are (if I counted correctly):
achalv: arrange
MatsPalmgren: place (4 likes)
jensimmons: place
rchrdnsh: place (2 likes)
SebastianZ: place (1 like)
liamquin: arrange
malyw: place
danilovaz: place (1 like)
dancork: arrange
rachelandrew: arrange

which seems to make place the winner.

Perhaps the CSSWG can make a decision so that we can start implementing it? :-)
Thanks.

MatsPalmgren commented Oct 26, 2016

@dbaron tells me that having a shorthand and longhand with the same name is impossible to implement in Gecko. So that excludes align as the prefix.

It appears that arrange and place are the two most popular prefixes, and I believe the separator must be something else than space (see my comments above), I suggest '/'.
So to write them out, we have:

arrange-items: <align-items> / <justify-items>
arrange-self: <align-self> / <justify-self>
arrange-content: <align-content> / <justify-content>

or

place-items: <align-items> / <justify-items>
place-self: <align-self> / <justify-self>
place-content: <align-content> / <justify-content>

(other prefixes suggested: compose distribute spread splay position align2d)

The voting tally for these two are (if I counted correctly):
achalv: arrange
MatsPalmgren: place (4 likes)
jensimmons: place
rchrdnsh: place (2 likes)
SebastianZ: place (1 like)
liamquin: arrange
malyw: place
danilovaz: place (1 like)
dancork: arrange
rachelandrew: arrange

which seems to make place the winner.

Perhaps the CSSWG can make a decision so that we can start implementing it? :-)
Thanks.

@astearns astearns added the Agenda+ label Oct 26, 2016

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Oct 26, 2016

BTW, a single value should also be allowed of course, even though
I didn't spell it out in the syntax above.

MatsPalmgren commented Oct 26, 2016

BTW, a single value should also be allowed of course, even though
I didn't spell it out in the syntax above.

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Nov 1, 2016

Contributor

It does sound like 'place' is the winner. :) Wrt slashes ... that unfortunately makes us inconsistent with the scroll-snap-align syntax. It'd be nice if we could stay consistent with that. This might mean introducing some syntactic restrictions, though. :/ I'm not sure what's a good answer here.

Contributor

fantasai commented Nov 1, 2016

It does sound like 'place' is the winner. :) Wrt slashes ... that unfortunately makes us inconsistent with the scroll-snap-align syntax. It'd be nice if we could stay consistent with that. This might mean introducing some syntactic restrictions, though. :/ I'm not sure what's a good answer here.

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Nov 1, 2016

Yeah, as I said above, there's both the ambiguity of something like:
place-content: end stretch end
which could mean:
align-content: end stretch
justify-content: end
or
align-content: end
justify-content: stretch end

and the ambiguity about if the value is a single value or not:
place-content: end stretch
could mean (as a single value):
align-content: end stretch
justify-content: end stretch
or (as two values)
align-content: end
justify-content: stretch

(and there are many variations of those ambiguities of course...)

So, my preference is to use / as the separator because it can represent all
values unambiguously. If you choose space, then I would recommend restricting
the value set to single-keyword[1] values only. That is,
place-content: end stretch
means
align-content: end
justify-content: stretch
(fallback value and <overflow-position> can't be specified using the shorthand)

Doing something more advanced (parsing eagerly) would be hard to grok for humans
and parsers alike. :-)

[1] in this context, last/first baseline counts as one keyword though

MatsPalmgren commented Nov 1, 2016

Yeah, as I said above, there's both the ambiguity of something like:
place-content: end stretch end
which could mean:
align-content: end stretch
justify-content: end
or
align-content: end
justify-content: stretch end

and the ambiguity about if the value is a single value or not:
place-content: end stretch
could mean (as a single value):
align-content: end stretch
justify-content: end stretch
or (as two values)
align-content: end
justify-content: stretch

(and there are many variations of those ambiguities of course...)

So, my preference is to use / as the separator because it can represent all
values unambiguously. If you choose space, then I would recommend restricting
the value set to single-keyword[1] values only. That is,
place-content: end stretch
means
align-content: end
justify-content: stretch
(fallback value and <overflow-position> can't be specified using the shorthand)

Doing something more advanced (parsing eagerly) would be hard to grok for humans
and parsers alike. :-)

[1] in this context, last/first baseline counts as one keyword though

@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Nov 1, 2016

Member

Yeah, we absolutely need a / here. We use it in the other places where we have ambiguous shorthands; it's not well-known, but it's becoming more common (used thruout Grid, for example). The syntactic restrictions necessary to make it unambiguous would be too restrictive, I think.

scroll-snap-align gets away without a slash because it's so incredibly simple. It's not great that we have to be inconsistent, but at least we're consistent with things like grid-area.

(And I'm happy with place-*.)

Member

tabatkins commented Nov 1, 2016

Yeah, we absolutely need a / here. We use it in the other places where we have ambiguous shorthands; it's not well-known, but it's becoming more common (used thruout Grid, for example). The syntactic restrictions necessary to make it unambiguous would be too restrictive, I think.

scroll-snap-align gets away without a slash because it's so incredibly simple. It's not great that we have to be inconsistent, but at least we're consistent with things like grid-area.

(And I'm happy with place-*.)

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Nov 2, 2016

Contributor

My concern here is that we have several places that take [ start | center | end ]{1,2} as a two-axis alignment--place-self/items/content, scroll-snap-align, and background-position (and possibly in the future, float)--and introducing a slash here makes them inconsistent.

Contributor

fantasai commented Nov 2, 2016

My concern here is that we have several places that take [ start | center | end ]{1,2} as a two-axis alignment--place-self/items/content, scroll-snap-align, and background-position (and possibly in the future, float)--and introducing a slash here makes them inconsistent.

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Nov 2, 2016

I think a space separator is fine as long as we restrict the values as specified above. I'm assuming that (non-default) fallback values and <overflow-position> are rarely needed.

MatsPalmgren commented Nov 2, 2016

I think a space separator is fine as long as we restrict the values as specified above. I'm assuming that (non-default) fallback values and <overflow-position> are rarely needed.

@astearns astearns removed the Agenda+ label Nov 8, 2016

@jensimmons

This comment has been minimized.

Show comment
Hide comment
@jensimmons

jensimmons Nov 16, 2016

Just to chime in, after living with this for a while, I really like place-*. I think it will fit well into the world of CSS.

I agree that a '/' separator makes a lot of sense too. People will be writing grid-area: 1 / 2 / 4 / 3; and place-items: center / end; at the same time.

Which goes first? Ah, vertical (in a horizontal-tb writing mode), then horizontal, like margins and grid? So — to summarize, like this, yes?

place-items: <'align-items'> / <'justify-items'>;
place-self: <'align-self'> / <'justify-self'>;
place-content: <'align-content'> / <'justify-content'>;

jensimmons commented Nov 16, 2016

Just to chime in, after living with this for a while, I really like place-*. I think it will fit well into the world of CSS.

I agree that a '/' separator makes a lot of sense too. People will be writing grid-area: 1 / 2 / 4 / 3; and place-items: center / end; at the same time.

Which goes first? Ah, vertical (in a horizontal-tb writing mode), then horizontal, like margins and grid? So — to summarize, like this, yes?

place-items: <'align-items'> / <'justify-items'>;
place-self: <'align-self'> / <'justify-self'>;
place-content: <'align-content'> / <'justify-content'>;
@keithjgrant

This comment has been minimized.

Show comment
Hide comment
@keithjgrant

keithjgrant Nov 16, 2016

Contributor

Hm, my inclination is for horizontal to go first. Properties w/ four values like margin, padding, and border-* go clockwise around all four sides—the vertical then horizontal shorthand is merely a truncated version of this—whereas properties that deal with x / y coordinates (e.g. background-position) are horizontal first. This seems to me more akin to the latter.

Then again, grid-area is a whole new order that doesn't really fit either of those paradigms. So maybe matching grid-area (vertical first) makes sense in this context.

Contributor

keithjgrant commented Nov 16, 2016

Hm, my inclination is for horizontal to go first. Properties w/ four values like margin, padding, and border-* go clockwise around all four sides—the vertical then horizontal shorthand is merely a truncated version of this—whereas properties that deal with x / y coordinates (e.g. background-position) are horizontal first. This seems to me more akin to the latter.

Then again, grid-area is a whole new order that doesn't really fit either of those paradigms. So maybe matching grid-area (vertical first) makes sense in this context.

@meyerweb

This comment has been minimized.

Show comment
Hide comment
@meyerweb

meyerweb Nov 16, 2016

In every situation I can think of where there are X and Y values, it’s usually X and then Y. As an example, transform: scale(2,0.5) makes the element wide and short, not tall and thin. background-position: 50% 100% is center bottom, not right center (though the keywords aren’t constrained to X,Y order, a fact which makes the value syntax for background-position a minor nightmare).

It’s possible the order could be defined to be writing-mode dependent, but the idea makes me uncomfortable in a way I find hard to articulate.

meyerweb commented Nov 16, 2016

In every situation I can think of where there are X and Y values, it’s usually X and then Y. As an example, transform: scale(2,0.5) makes the element wide and short, not tall and thin. background-position: 50% 100% is center bottom, not right center (though the keywords aren’t constrained to X,Y order, a fact which makes the value syntax for background-position a minor nightmare).

It’s possible the order could be defined to be writing-mode dependent, but the idea makes me uncomfortable in a way I find hard to articulate.

@jensimmons

This comment has been minimized.

Show comment
Hide comment
@jensimmons

jensimmons Nov 17, 2016

Well, the order will be writing-mode dependent, because it's defining a shortcut for align-* and justify-* which do change based on either the writing-mode or the flex/grid direction. But I agree, the order justify / align or 'align / justify` should always be the same, and not change. It's just that whether each affects X or Y axis directions will change.

Ah, complexity.

I'm hearing folks advocate that this is more consistent with other CSS:

place-items: <'justify-items'> / <'align-items'>;
place-self: <'justify-self'> / <'align-self'>;
place-content: <'justify-content'> / <'align-content'>;

Handle what is (in the defaults of horizontal-tb writing mode with flex-direction: row or grid-auto-flow: row) typically in the X-direction first, followed by the Y-direction.

Just for reference, making and padding start with top, and rotate clockwise, while grid-area starts with top and rotates counter-clockwise. It makes sense to me to make place-* follow the patterns set by CSS that has X & Y, rather than four values, if in fact those aren't consistent.

I'm going to ask around what people think would be better for this, to get some more voices.

jensimmons commented Nov 17, 2016

Well, the order will be writing-mode dependent, because it's defining a shortcut for align-* and justify-* which do change based on either the writing-mode or the flex/grid direction. But I agree, the order justify / align or 'align / justify` should always be the same, and not change. It's just that whether each affects X or Y axis directions will change.

Ah, complexity.

I'm hearing folks advocate that this is more consistent with other CSS:

place-items: <'justify-items'> / <'align-items'>;
place-self: <'justify-self'> / <'align-self'>;
place-content: <'justify-content'> / <'align-content'>;

Handle what is (in the defaults of horizontal-tb writing mode with flex-direction: row or grid-auto-flow: row) typically in the X-direction first, followed by the Y-direction.

Just for reference, making and padding start with top, and rotate clockwise, while grid-area starts with top and rotates counter-clockwise. It makes sense to me to make place-* follow the patterns set by CSS that has X & Y, rather than four values, if in fact those aren't consistent.

I'm going to ask around what people think would be better for this, to get some more voices.

@jensimmons

This comment has been minimized.

Show comment
Hide comment
@jensimmons

jensimmons Nov 17, 2016

Let me ask this more succinctly, so more voices can chime in.

When you are writing code for Flexbox or Grid, you can specify how the browser allocates space by saying things like:

justify-content: space-between;
align-content: center;

We are proposing a shorter way to say such things. How should this example be shortened?

Option A:

place-content: space-between / center;

Option B:

place-content: center / space-between;

jensimmons commented Nov 17, 2016

Let me ask this more succinctly, so more voices can chime in.

When you are writing code for Flexbox or Grid, you can specify how the browser allocates space by saying things like:

justify-content: space-between;
align-content: center;

We are proposing a shorter way to say such things. How should this example be shortened?

Option A:

place-content: space-between / center;

Option B:

place-content: center / space-between;
@una

This comment has been minimized.

Show comment
Hide comment
@una

una Nov 17, 2016

To start, I want to say that I like the idea of the place-* prefix, and I can see the consistency here with other CSS conventions.

However, I'm worried that this can get confusing though (the existence of all of these properties):

justify-content: space-between;
align-content: center;
place-content: space-between

Looking at those without prior knowledge, it's hard to understand what they all mean individually, and how to remember the nuances. Maybe prepending with grid might help?

grid-place-items: <'justify-items'> / <'align-items'>;
grid-place-self: <'justify-self'> / <'align-self'>;
grid-place-content: <'justify-content'> / <'align-content'>;

And then a shortcut for all of them can be:

grid-placement: <grid-place-items> <grid-place-self> <grid-place-content>

^ These will likely all be used together anyway to build layouts.

una commented Nov 17, 2016

To start, I want to say that I like the idea of the place-* prefix, and I can see the consistency here with other CSS conventions.

However, I'm worried that this can get confusing though (the existence of all of these properties):

justify-content: space-between;
align-content: center;
place-content: space-between

Looking at those without prior knowledge, it's hard to understand what they all mean individually, and how to remember the nuances. Maybe prepending with grid might help?

grid-place-items: <'justify-items'> / <'align-items'>;
grid-place-self: <'justify-self'> / <'align-self'>;
grid-place-content: <'justify-content'> / <'align-content'>;

And then a shortcut for all of them can be:

grid-placement: <grid-place-items> <grid-place-self> <grid-place-content>

^ These will likely all be used together anyway to build layouts.

@jondaiello

This comment has been minimized.

Show comment
Hide comment
@jondaiello

jondaiello Nov 17, 2016

Option A makes the most sense to me. It places the main axis first, then the cross axis.

jondaiello commented Nov 17, 2016

Option A makes the most sense to me. It places the main axis first, then the cross axis.

@jonathantneal

This comment has been minimized.

Show comment
Hide comment
@jonathantneal

jonathantneal Nov 17, 2016

Contributor

I love shorthands, and I love the idea of putting main and cross alignment into a single thought.

I think @una is wise to point out that another -content, -self, or -items property may confuse developers, especially if place-* works as a synonym for only one of the other properties (e.g. if place-content: center is the same as justify-content: center and has no effect on on align-content).

Would it be possible to use the divider / to skip the initial property?

/* shorthand */
place-content: / center;

/* equivalent */
align-content: center;

You’re welcome to experiment with this syntax @ https://jonathantneal.github.io/postcss-place/


UPDATE: convention seems to be that shorthands always reset longhands. Therefore, I’m still hoping for a skip character, like *, e.g:

/* shorthand */
place-content: * / center;

/* equivalent */
align-content: center;
Contributor

jonathantneal commented Nov 17, 2016

I love shorthands, and I love the idea of putting main and cross alignment into a single thought.

I think @una is wise to point out that another -content, -self, or -items property may confuse developers, especially if place-* works as a synonym for only one of the other properties (e.g. if place-content: center is the same as justify-content: center and has no effect on on align-content).

Would it be possible to use the divider / to skip the initial property?

/* shorthand */
place-content: / center;

/* equivalent */
align-content: center;

You’re welcome to experiment with this syntax @ https://jonathantneal.github.io/postcss-place/


UPDATE: convention seems to be that shorthands always reset longhands. Therefore, I’m still hoping for a skip character, like *, e.g:

/* shorthand */
place-content: * / center;

/* equivalent */
align-content: center;
@AmeliaBR

This comment has been minimized.

Show comment
Hide comment
@AmeliaBR

AmeliaBR Nov 17, 2016

I agree that the most consistent ordering, based on other two-value CSS properties, is justify-* (inline/main-flex direction) followed by align-* (block/cross-flex direction). In the default cases (grid in horizontal writing mode and flex with rows) this matches the normal (x,y) horizontal then vertical ordering.

I also agree with place-* as the prefix: it is a simple word, not used elsewhere in CSS syntax, and works equally well when discussing child items/content or self.

Question about the general syntax:

Would place-items: center be a valid shorthand for justify-items: center and align-items: center? Or would you need to spell it out as place-items: center / center ? (Or would place-items: center be equal to place-items: center / initial?)

Allowing a shorter shorthand would be nice, but it complicates the syntax, since the align and justify properties have different allowed values. I would be tempted to force both values to be provided for place-*. If for no other reason, it would help avoid name confusion: If you always see the place-* properties with two slash-separated values, it would help remind you that this is the property that sets two others!

Edit: I read @jonathantneal's comment after posting.

I'm assuming that, one way or another, the place-* shorthand would reset both longhands. If you don't want to reset, you would use justify-* or align-*.

AmeliaBR commented Nov 17, 2016

I agree that the most consistent ordering, based on other two-value CSS properties, is justify-* (inline/main-flex direction) followed by align-* (block/cross-flex direction). In the default cases (grid in horizontal writing mode and flex with rows) this matches the normal (x,y) horizontal then vertical ordering.

I also agree with place-* as the prefix: it is a simple word, not used elsewhere in CSS syntax, and works equally well when discussing child items/content or self.

Question about the general syntax:

Would place-items: center be a valid shorthand for justify-items: center and align-items: center? Or would you need to spell it out as place-items: center / center ? (Or would place-items: center be equal to place-items: center / initial?)

Allowing a shorter shorthand would be nice, but it complicates the syntax, since the align and justify properties have different allowed values. I would be tempted to force both values to be provided for place-*. If for no other reason, it would help avoid name confusion: If you always see the place-* properties with two slash-separated values, it would help remind you that this is the property that sets two others!

Edit: I read @jonathantneal's comment after posting.

I'm assuming that, one way or another, the place-* shorthand would reset both longhands. If you don't want to reset, you would use justify-* or align-*.

@mrego

This comment has been minimized.

Show comment
Hide comment
@mrego

mrego Nov 17, 2016

Member

Note that for all grid layout properties the format is "rows / columns". E.g. grid-template: grid-template-rows / grid-template-columns or grid-gap: grid-row-gap grid-column-gap.

So IMHO place-content should follow the "rows / columns" order too, and it should be align-content / justify-content (option B).

Member

mrego commented Nov 17, 2016

Note that for all grid layout properties the format is "rows / columns". E.g. grid-template: grid-template-rows / grid-template-columns or grid-gap: grid-row-gap grid-column-gap.

So IMHO place-content should follow the "rows / columns" order too, and it should be align-content / justify-content (option B).

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Nov 18, 2016

I'm in favor of option B, for consistency with (all) the Grid shorthands.

MatsPalmgren commented Nov 18, 2016

I'm in favor of option B, for consistency with (all) the Grid shorthands.

@jonathantneal

This comment has been minimized.

Show comment
Hide comment
@jonathantneal

jonathantneal Nov 18, 2016

Contributor

@mrego, does grid-template: grid-template-rows without the divider or secondary grid-template-columns value still reset the grid-template-columns property? If it does reset that property, would you know the answer to @AmeliaBR’s question; does it reset the property to initial or use the same value as being given to grid-template-rows?

UPDATE: According to MDN, the “grid shorthand accepts the same syntax, but also resets the implicit grid properties to their initial values.

Contributor

jonathantneal commented Nov 18, 2016

@mrego, does grid-template: grid-template-rows without the divider or secondary grid-template-columns value still reset the grid-template-columns property? If it does reset that property, would you know the answer to @AmeliaBR’s question; does it reset the property to initial or use the same value as being given to grid-template-rows?

UPDATE: According to MDN, the “grid shorthand accepts the same syntax, but also resets the implicit grid properties to their initial values.

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Nov 18, 2016

@jonathantneal

each “missing” sub-property is assigned its initial value.
https://drafts.csswg.org/css-cascade-4/#shorthand-property

MatsPalmgren commented Nov 18, 2016

@jonathantneal

each “missing” sub-property is assigned its initial value.
https://drafts.csswg.org/css-cascade-4/#shorthand-property

@mrego

This comment has been minimized.

Show comment
Hide comment
@mrego

mrego Nov 18, 2016

Member

@jonathantneal in the particular case of grid-template you've to provide both values or the declaration is invalid:

  • grid-template: 100px 100px / 200px 200px 200px: Ok
  • grid-template: 100px 100px / none: Ok
  • grid-template: none / 200px 200px 200px: Ok
  • grid-template: 100px 100px: Invalid
  • grid-template: / 200px 200px 200px: Invalid

I believe that for place-* if we set only one value it could be used for both align-* and justify-*. For example:

  • place-content: center / end => align-content: center; justify-content: end
  • place-content: center => align-content: center; justify-content: center
Member

mrego commented Nov 18, 2016

@jonathantneal in the particular case of grid-template you've to provide both values or the declaration is invalid:

  • grid-template: 100px 100px / 200px 200px 200px: Ok
  • grid-template: 100px 100px / none: Ok
  • grid-template: none / 200px 200px 200px: Ok
  • grid-template: 100px 100px: Invalid
  • grid-template: / 200px 200px 200px: Invalid

I believe that for place-* if we set only one value it could be used for both align-* and justify-*. For example:

  • place-content: center / end => align-content: center; justify-content: end
  • place-content: center => align-content: center; justify-content: center
@lozandier

This comment has been minimized.

Show comment
Hide comment
@lozandier

lozandier Nov 18, 2016

Between place && arrange, place seems like a better prefix to me.

lozandier commented Nov 18, 2016

Between place && arrange, place seems like a better prefix to me.

@jonathantneal

This comment has been minimized.

Show comment
Hide comment
@jonathantneal

jonathantneal Nov 18, 2016

Contributor

Thanks @mrego. I’ve gone ahead and updated the demo to reflect that change. I’ve filed a separate issue to address skipping parts of a shorthand.

Contributor

jonathantneal commented Nov 18, 2016

Thanks @mrego. I’ve gone ahead and updated the demo to reflect that change. I’ve filed a separate issue to address skipping parts of a shorthand.

@huijing

This comment has been minimized.

Show comment
Hide comment
@huijing

huijing Nov 18, 2016

Contributor

At first I felt Option A (main axis first, then cross axis) made sense, because the writing-mode could be vertical and still be consistent. However, I realised that the grid-area shorthand is row-start, column-start, row-end, column-end. When a vertical writing-mode is applied, what is termed as row now runs vertical and column runs horizontal. In this case, it's probably better to keep it consistent with the grid shorthand for consistency's sake.

Contributor

huijing commented Nov 18, 2016

At first I felt Option A (main axis first, then cross axis) made sense, because the writing-mode could be vertical and still be consistent. However, I realised that the grid-area shorthand is row-start, column-start, row-end, column-end. When a vertical writing-mode is applied, what is termed as row now runs vertical and column runs horizontal. In this case, it's probably better to keep it consistent with the grid shorthand for consistency's sake.

@astearns astearns added the Agenda+ label Nov 18, 2016

@astearns

This comment has been minimized.

Show comment
Hide comment
@astearns

astearns Nov 18, 2016

Member

Adding agenda+ back in to decide on the syntax for the value (I should have opened a new issue for this, but I didn't and the syntax discussion happened here anyway)

Member

astearns commented Nov 18, 2016

Adding agenda+ back in to decide on the syntax for the value (I should have opened a new issue for this, but I didn't and the syntax discussion happened here anyway)

@rchrdnsh

This comment has been minimized.

Show comment
Hide comment
@rchrdnsh

rchrdnsh Nov 19, 2016

Does anybody have a good source on the origin and reasoning behind using the word 'justify' in typography and typesetting? I'm rather new to all this (web design and typography) and that is one of the terms I still don't 'get' in this context. In my head, instead of 'justify-content' the phrase 'horizontal-align' makes more sense. Then 'align-content' could be 'vertical-align', and then the shorthand for both could simply be 'align'. Again, apologies for any ignorance on my part, as I am still 'struggling' with the logic of the 'justify' term, among others, in the context of typography.

rchrdnsh commented Nov 19, 2016

Does anybody have a good source on the origin and reasoning behind using the word 'justify' in typography and typesetting? I'm rather new to all this (web design and typography) and that is one of the terms I still don't 'get' in this context. In my head, instead of 'justify-content' the phrase 'horizontal-align' makes more sense. Then 'align-content' could be 'vertical-align', and then the shorthand for both could simply be 'align'. Again, apologies for any ignorance on my part, as I am still 'struggling' with the logic of the 'justify' term, among others, in the context of typography.

@astearns

This comment has been minimized.

Show comment
Hide comment
@astearns

astearns Nov 19, 2016

Member

@rchrdnsh in western typography justification refers to horizontal adjustments of type in the line, so it seems apt to me. One problem with horizontal- and vertical- is that the axes are swapped in vertical text, and we want the same term to apply for in-line adjustments in both cases.

Member

astearns commented Nov 19, 2016

@rchrdnsh in western typography justification refers to horizontal adjustments of type in the line, so it seems apt to me. One problem with horizontal- and vertical- is that the axes are swapped in vertical text, and we want the same term to apply for in-line adjustments in both cases.

@liamquin

This comment has been minimized.

Show comment
Hide comment
@liamquin

liamquin Nov 19, 2016

On Sat, 2016-11-19 at 12:26 -0800, rchrdnsh wrote:

Does anybody have a good source on the origin and reasoning behind
using the word 'justify' in typography and typesetting?

It's been in use for a long time -- e.g. it's in my 1736 copy of
Bailey's dictionary, as well as Jacobi's 1888 dictionary of printing
terms [1], where he describes justifying a stick, or composing-stick. 

I'm not sure what the origin was (possibly via the Latin, to make just,
or to make even, since justification makes the edges of the text even)
but I don't think it would be productive for CSS to try and change it,
even if it were not already in widespread use in CSS. You might as well
ask why a typeface implementation is called a font and not (as it once
was) a fount, or (as I think it never was) a murder mystery, despite
containing some shady characters.

Liam

[1] http://words.fromoldbooks.org/Jacobi-PrintersVocabulary/j/justifyin
g-a-stick.html

Liam R. E. Quin liam@w3.org
The World Wide Web Consortium (W3C)

liamquin commented Nov 19, 2016

On Sat, 2016-11-19 at 12:26 -0800, rchrdnsh wrote:

Does anybody have a good source on the origin and reasoning behind
using the word 'justify' in typography and typesetting?

It's been in use for a long time -- e.g. it's in my 1736 copy of
Bailey's dictionary, as well as Jacobi's 1888 dictionary of printing
terms [1], where he describes justifying a stick, or composing-stick. 

I'm not sure what the origin was (possibly via the Latin, to make just,
or to make even, since justification makes the edges of the text even)
but I don't think it would be productive for CSS to try and change it,
even if it were not already in widespread use in CSS. You might as well
ask why a typeface implementation is called a font and not (as it once
was) a fount, or (as I think it never was) a murder mystery, despite
containing some shady characters.

Liam

[1] http://words.fromoldbooks.org/Jacobi-PrintersVocabulary/j/justifyin
g-a-stick.html

Liam R. E. Quin liam@w3.org
The World Wide Web Consortium (W3C)

@jensimmons

This comment has been minimized.

Show comment
Hide comment
@jensimmons

jensimmons Nov 23, 2016

So, this:

place-items: <'align-items'> <'justify-items'>;
place-self: <'align-self'> <'justify-self'>;
place-content: <'align-content'> <'justify-content'>;

where only single-keyword values are allowed.

jensimmons commented Nov 23, 2016

So, this:

place-items: <'align-items'> <'justify-items'>;
place-self: <'align-self'> <'justify-self'>;
place-content: <'align-content'> <'justify-content'>;

where only single-keyword values are allowed.

@jensimmons

This comment has been minimized.

Show comment
Hide comment
@jensimmons

jensimmons Nov 23, 2016

I just want to say thanks to everyone who was debating the order of the values above. I probably shouldn't have opened that part of the question, though. Turns out the CSSWG had a big long debate and make a big key decision about order of everything like this a while ago (over a year ago?) and so this question was already decided. It's clear that the order for place-* should be align-* first, then justify-*. This matches the decision to always put block-direction stuff first, then baseline direction stuff. So... sorry. And thanks. And hopefully it all becomes super second nature to us all once we are using it a lot. Just think: Block first. Then inline. Block first. Then inline.

jensimmons commented Nov 23, 2016

I just want to say thanks to everyone who was debating the order of the values above. I probably shouldn't have opened that part of the question, though. Turns out the CSSWG had a big long debate and make a big key decision about order of everything like this a while ago (over a year ago?) and so this question was already decided. It's clear that the order for place-* should be align-* first, then justify-*. This matches the decision to always put block-direction stuff first, then baseline direction stuff. So... sorry. And thanks. And hopefully it all becomes super second nature to us all once we are using it a lot. Just think: Block first. Then inline. Block first. Then inline.

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Nov 24, 2016

Contributor

Just some background on the slightly-off-topic bits of this issue...
Discussion from decision to have block-axis first, inline-axis second:

Background on align/justify terminology: https://lists.w3.org/Archives/Public/www-style/2012Feb/0743.html

The WG resolution today was to use space as a separator and to keep the valid values for the shorthand, as jensimmons wrote, restricted to single keyword values. I'll update the spec accordingly.

Contributor

fantasai commented Nov 24, 2016

Just some background on the slightly-off-topic bits of this issue...
Discussion from decision to have block-axis first, inline-axis second:

Background on align/justify terminology: https://lists.w3.org/Archives/Public/www-style/2012Feb/0743.html

The WG resolution today was to use space as a separator and to keep the valid values for the shorthand, as jensimmons wrote, restricted to single keyword values. I'll update the spec accordingly.

@yisibl

This comment has been minimized.

Show comment
Hide comment
@yisibl

yisibl Nov 25, 2016

place +1

yisibl commented Nov 25, 2016

place +1

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Nov 26, 2016

Contributor

Fixed in ca03e49

Contributor

fantasai commented Nov 26, 2016

Fixed in ca03e49

@fantasai fantasai closed this Nov 26, 2016

@fantasai fantasai removed the Agenda+ label Nov 26, 2016

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Jan 3, 2017

Contributor

For future reference... https://www.w3.org/TR/css3-background/#the-border-radius uses slashes between the x and y axes, not between sides. (But in general, it seems slashes in CSS are weird.)

Contributor

fantasai commented Jan 3, 2017

For future reference... https://www.w3.org/TR/css3-background/#the-border-radius uses slashes between the x and y axes, not between sides. (But in general, it seems slashes in CSS are weird.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment