Skip to content
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-grid-1][css-grid-2] Basic support for "equal gutter" with justify-content on grid items #1116

Closed
hunboy opened this issue Mar 20, 2017 · 15 comments

Comments

@hunboy
Copy link

hunboy commented Mar 20, 2017

[css-grid-1][css-grid-2]
https://drafts.csswg.org/css-grid/#gutters

Motivation: the users often want equal (horizontally, vertically) gaps for stilistic reasons.

Currently the grid-row-gap doesn't support the equal value when justify-content is defined.

As a workaround I present 3 javascript algorythms to make equal gutter between the grid items when justify-content is defined.

(for testing resize the frame - the 100 value in the script is same as the grid-item's width, so it's hardcoded by constant)

Resolution: So some basic support would be good for gaps. Perhaps "grid-row-gap: auto", or some keyword to define equal gutter for the grid system.

@fantasai
Copy link
Collaborator

Just to summarize, the example is

  • definite width, auto height grid container
  • auto-fill columns e.g. 100px
  • auto-placed items
  • place-content: space-between
    The spacing produced by space-between is not equal in both axes.

I think there are two possible solutions here:

  1. Invent some new syntax to make this happen.
  2. Define that if an axis is auto-sized (and therefore justification space would be zero), justification space is instead copied from the other axis. (This is not a far stretch from how we handle frs.)

@tabatkins
Copy link
Member

Reusing any existing syntax makes this a level 1 feature, and level 1 has been in feature freeze for some time now, so if we address this it'll be with new syntax.

@fantasai
Copy link
Collaborator

fantasai commented Nov 6, 2017

Agenda+ to request some ideas. We should fix this by the L2 FPWD.

@css-meeting-bot
Copy link
Member

The Working Group just discussed "Equal Gutter" with justify-content.

The full IRC log of that discussion <frremy> Topic: "Equal Gutter" with justify-content
<astearns> github: https://github.com//issues/1116
<frremy> fantasai: users often want row-gaps and col-gaps to be equal
<frremy> fantasai: but they also want the horizontal gaps to fill the remaining space once you've put as many columns as possible in the width direction
<frremy> fantasai: they can do that using justify-content
<frremy> fantasai: but they cannot transfer this size in the other direction
<frremy> fantasai: this is basically a request for thoughts on the topic
<fantasai> https://github.com//issues/1116#issuecomment-288472394
<fantasai> Just to summarize, the example is
<fantasai> definite width, auto height grid container
<fantasai> auto-fill columns e.g. 100px
<fantasai> auto-placed items
<fantasai> place-content: space-between
<fantasai> The spacing produced by space-between is not equal in both axes.
<frremy> jensimmons: so is the idea { row-gap: as-column-gap }
<frremy> jensimmons: ?
<frremy> TabAtkins: pretty much
<frremy> (general discussion, but it was thought to minute)
<TabAtkins> s/thought/tough/
<frremy> fantasai: the tricky thing is that two things control the gap size
<frremy> fantasai: the gap property
<frremy> fantasai: and the alignment properties
<frremy> fantasai: you do have to consider both to get the desired effect
<frremy> fantasai: and there are interersting cases of space-evenly which creates a gap before the first column and after the last column, we will need to define what to do about that
<fantasai> the gap properties only distribute space between the columns, but alignment can do other things
<frremy> florian: and the proposed syntax would allow to also define alignment in the direction in which you said to copy
<frremy> florian: I think we should have a more restrictive syntax that doesn't allow the impossible cases would be better
<frremy> florian: but I don't have a concrete proposal right now
<frremy> jensimmons: just to clarify, the alignment do not update the gap, they add a gutter right?
<frremy> fantasai: yes, but visually it looks like the same thing
<frremy> jensimmons: so it looks like we want something to transfer the gutter not the gap
<frremy> dholbert: maybe some align: symmetrical then?
<frremy> dholbert: alignment properties already are allowed to increase a gap
<frremy> dholbert: it would be possible to also shrink the gap to make it match, that doesn't sound unreasonable
<dholbert> Or possibly not shrink, but grow-or-leave-the-same (to avoid)
<frremy> Rossen: alright, I think we should probably break out to lunch, and have people interested in this proposal talk with each other
<frremy> Rossen: let's get back here at 1.30
<dholbert> *(to avoid violating author expectations that "grid-row-gap: 100px" should actually insert at least 100px of space)

@fantasai
Copy link
Collaborator

Proposal...

Name: align-content, justify-content
New values: [ <number> && <content-distribution>? ]

<number>
: Represents a multiplier against the analogous quantity in the other dimension. If that quantity cannot be determined (e.g. is itself specified as a ratio, or otherwise can’t be referenced), then it is assumed to be zero. Specifically,

  • For align-content, 1 represents the amount of space allocated between two adjacent lines/tracks/etc. by the justify-content property. (This value will be zero if justify-content does not allocates space between adjacent alignment subjects either due to not having a <content-distribution> value or due to there being fewer than two alignment subjects.)
  • Unless a different <content-distribution> value is specified, space is distributed according to the same <content-distribution> rules as for justify-content.
  • The behavior of a <number> value for justify-content is analogous to align-content.
  • If both align-content and justify-content have <number> values, then justify-content’s number value has no effect. justify-content takes align-content’s <content-distribution> value, if one was specified, and falls back to space-between otherwise.

Note: This value can force extra space to be placed in gutters even when there is no free space left, causing oveflow.

In this example, a minimum of 1em is required between rows and columns. Additionally, any extra space in the inline axis that is distributed between columns, with full-size spaces on either side of the outermost columns. The gaps between rows are increased to match the extra space distributed between adjacent columns, but no space is added before the first row or after the last one.

.grid {
  grid-template-columns: repeat(auto-fill, 15em);
  gap: 1em;
  justify-content: space-evenly;
  align-content: 1 space-between;
}

This next example is the same as the previous, except that the ratio between row and column gaps is φ:

.grid {
  grid-template-columns: repeat(auto-fill, 15em);
  gap: 1em 1.618em;
  justify-content: space-evenly;
  align-content: .618 space-between;
}

... Thoughts?

@javifernandez
Copy link
Contributor

javifernandez commented Jan 31, 2018

I'm not sure if the new value's syntax should allow 'stretch'. Maybe I don't understand completely the proposal, but what would be the behavior of align-content: 2 stretch ?

@javifernandez
Copy link
Contributor

How this new value will be used in the place-content shorthand ? Some possibly ambiguous expressions that came to my mind:

  • place-content: 1 start -> align-content: 1 (space-between) / justify-content: start
  • place-content: 1 space-around 2 ->align-content 1 space-around / justify-content: 2
  • place-content: space-evenly 2 -> align-content: space-evenly / justify-content: 2

Shouldn't forbid this new value from the place-content shorthand's syntax ?

@javifernandez
Copy link
Contributor

Another issue that I'd like to note down here is how we want to deal with the different scenarios producing overflow:

  • height: auto - we will use the gaps to compute the final height. However, this new Content Distribution value will add extra size. Would this imply overflowing even with height auto ? Should we use the Content Distribution extra space, added to preserve the aspect ratio to compute the final grid's height ?

  • height: fixed - I'm not sure if this new value, intended to preserve the aspect ratio, should end up causing an overflow. I think aspect-ratio preservation should only be allowed with height: auto.

In general, I find it weird that properties that were initially defined to "distribute the available free space" ended up adding extra space, even when there is no free space left.

@javifernandez
Copy link
Contributor

If we accept that the Content Distribution properties may increase the grid's height, how this would affect to the track sizing algorithm and the content-sized tracks ?

@css-meeting-bot
Copy link
Member

The Working Group just discussed [css-grid-1][css-grid-2] Basic support for "equal gutter" with justify-content on grid items, and agreed to the following resolutions:

  • RESOLVED: Add the feature proposed in issue #1116 to Grid L2
  • RESOLVED: Publish FPWD for Grid L2
The full IRC log of that discussion <dael> Topic: [css-grid-1][css-grid-2] Basic support for "equal gutter" with justify-content on grid items
<dael> github: https://github.com//issues/1116
<dael> Rossen_: This is, if I recall, the newly added functionality to Grid L2.
<dael> fantasai: There is a justify-content prop that takes values to be put inbetween. You can center tracks, space them to the left or right, kinda like flex items. When people have a grid they want to auto-distribute, but have equal spacing in both axes. Right now no way to get that.
<dael> fantasai: This proposal has a possible value where it means go look at the other direction and use it over here multiplied by a number.
<lajava> yes
<dael> Rossen_: Do we have lajava?
<dael> Rossen_: I see they've made comments on the issue.
<Rossen_> s/lajava/javifernandez/
<lajava> rego and me are attending from igalia
<dael> Rossen_: I read through them. Seems there could be ambig as to how this could be helpful.
<dael> fantasai: What proposal does is what was requested. I'm happy to entertain other syntatic options, but we should solve the problem. What happens in each case should be worked through. Stretch shouldn't be allowed in combo.
<dael> Rossen_: And from your proposed solutions you had 2 options. 1 to introduce a new syntax and the other was define what happens if axis is auto size and space is justified instead of copied. Which of the two proposals do you want to discuss?
<dael> fantasai: I'm happy to entertain either. I think the proposal without syntax don't allow different propostions and would also change existing behavior so probably not the way we can go as TabAtkins noted last March.
<dael> florian: The unitless number one seemed to make sense to me. I think TabAtkins has reservations about unitless numbers because they don't meshed will with typedOM.
<dael> fantasai: In this case it's a multiplier and I don't know what unit we'd want to introduce.
<dael> florian: It's a % of some kind that just doesn't say so.
<dael> fantasai: We could use % also.
<dael> florian: % Isn't used there?
<dael> fantasai: Just alignment keywords. We could add % to them in the future for the % of the amount from start to end. For that reason if we go in that direction it might be a good idea to not use %.
<dael> Rossen_: I would stay away from % as well.
<dael> fantasai: This effectively represents an aspect ratio of sorts.
<dael> florian: Fair enough.
<dael> florian: I don't mind. I just thought abfelt introducing unitless things makes other hthings worse.
<florian> s/abfelt/tab felt/
<dael> fantasai: If someone doesn't like this proposal and wants to work on an alternate that's fine, but I don't have another alternative.
<florian> it seems sensible to me.
<dael> Rossen_: I think this is a reasonable starting point. By the time we're done we might change, but as a starting point the proposed solution addresses this feature request.
<dael> Rossen_: I'd like to hear if there are other thoughts or proposals. If there are additional syntax issues we can deal separetely.
<dael> Rossen_: I'm not hearing pushback on the proposed way to solve and impl.
<dael> Rossen_: Are there any or any objections?
<rachelandrew> +1 to adding the feature
<dael> Rossen_: There's a fair interest in this feature. Others last week gave thumbs up. I think it's reasonable to accept as level 2.
<dael> Rossen_: Are there any objections or additional comments?
<dael> RESOLVED: Add the feature proposed in issue #1116 to Grid L2
<rego> lajava, is having problems with the mic
<dael> fantasai: Do we want to do FPWD?
<fantasai> rego, maybe type in comment into IRC and we'll relay?
<lajava> yes, sorry, nothing urgent that can't be dicussed offline
<dael> Rossen_: Exactly. We can proceed to now resolve on FPWD for grid. Which will be potentially all the L1 delta incl subgrid and this new grid gutter feature
<dael> Rossen_: I believe that's everything in L2, right?
<Chris_> so is the document ready to go for fpwd or does it need edits first?
<rego> we don't have a better proposal, but we've some doubts regarding how it'll work for grid containers with "height: auto", if after alignment it'll overflow or if it'll change the height of the container
<dael> fantasai: Yeah, this is all I intend for L2. We should focus on subgrid and this feature was straightfoward.
<rego> but as we don't have a better proposal, I believe current one is fine as strating point
<dael> Rossen_: Yeah. On our end we reviewed and we're fine with FPWD.
<Chris_> I prefer that we are ready to go before resolving to request the transition
<lajava> my concerns are specially related to the fact tha Content Distibution increase the size of the contauner, instead of using the available space (even causing overflow)
<tantek> ship it
<dael> Rossen_: If there are no obj we'll resolve.
<dael> Chris_: The doc is ready to go as is now? features we want are in?
<dael> fantasai: Yes, just need to be regenerated.
<dael> Rossen_: There's no features we don't want. I had reservations last week, but we reviewed and we're good.
<dael> Chris_: +1
<dael> RESOLVED: Publish FPWD for Grid L2
<fantasai> lajava, rego: These are good points, let's work through them in WD.
<dael> Rossen_: Congrats and thank you.

@css-meeting-bot
Copy link
Member

The Working Group just discussed gutters, and agreed to the following resolutions:

  • RESOLVED: add an ar unit to the grid 2 spec for align content and justify content
The full IRC log of that discussion <astearns> topic: gutters
<astearns> github: https://github.com//issues/1116
<dael> fantasai: We resolved to add this to the first level of the WD. Just a request for people to let me know.
<dael> TabAtkins: Other then that I want a unit on these I think it looks great.
<dael> fantasai: unit proposed is ar unit for aspect ratio
<dael> astearns: Two options are a bare number or an ar unit
<dael> fantasai: I'm open to name suggestions
<dael> TabAtkins: I regret not putting unit on flex.
<dael> astearns: Could ar be used in other places?
<dael> TabAtkins: A generic aspect ratio
<dael> florian: It's mathematically unitless.
<dael> fantasai: It's a multiplier.
<dael> TabAtkins: Whatever the other thing results in multiply it.
<dael> florian: Does the unit thing play into if we want to ever use calc on it.
<dael> TabAtkins: Numbers tend to cause parsing issues. It causes issues on the flex things. I'd prefer not to keep that. This has a specific meaning so it should be tagged in a specific way. agnles are just numbers.
<dael> fantasai: They're not.
<dael> TabAtkins: They're radians which are just an ID.
<dael> fantasai: Somewhat releated discussion has been aspect ratio units needed, #1173
<ChrisL> how are radians an ID?
<dael> fantasai: There was a request for having an aspect ratio in the grid spec. A lot of the cases we want to have are covered by an aspect ratio property. Question was if there isn't an element can you asign the aspect ratio property.
<TabAtkins> ChrisL, Radian is (length of arc) / (length of radius), which is unitless
<ChrisL> an aspect ratio is (by definition) a ratio. It is a length divided by a length, and thus also unitless.
<dael> fantasai: You might decde you have a bunc hof fr columns and you want the rows to be 1:1. Once we add this if there's at least one element you can key off of you can auto-size the rest. If you don't put anything the auto row collapses to 0.
<dael> astearns: The only things in having that row were spanning it would be weird.
<TabAtkins> Yes, that's my point. We already associate units with "unitless" things, to give it an easily-interpreted meaning and help with parsing. THis is the same deal.
<dael> fantasai: One proposal was to have an ar unit in grid template columns that would represent the aspect ratio multiplied by the axis. QUestion was what if they are different sizes
<dael> fantasai: Proposal I had is 1ar is always 1fr in the other.
<dael> florian: You can't map to a colum 'cause you don't know which ot match.
<dael> fantasai: I'ts not clear what we need to do.
<dael> astearns: And a side discussion.
<dael> fantasai: A unit may be useful in this case.
<ChrisL> remember though that whenever we add units, it stops those things being used in custom properties, because we can't divide by united values
<dael> astearns: So do you want to resolve to add a ar unit?
<dael> TabAtkins: If we accept hte gap syntax I feel we should have a unit.
<dael> ChrisL: Remember when we add units you can't use them in custom properties. You can't devide by an ar.
<dael> TabAtkins: You can, ot works now.
<dael> astearns: Objections to adding an ar unit to the grid 2 spec for align content and justify content?
<TabAtkins> (I've been slow to add the functionality to calc(), but we resolved to do so a while back, and Typed OM allows it.)
<dael> RESOLVED: add an ar unit to the grid 2 spec for align content and justify content

@mrego
Copy link
Member

mrego commented Apr 16, 2018

I was talking about some of the issues described by @javifernandez with @rachelandrew past week.
I'm adding here an example as we were not sure what would be the preferred behvaior from web authors point of view.

Imagine that you have a grid container like this:

  display: grid;
  grid: 50px 50px / 100px 100px;
  justify-content: space-between;
  align-content: 1ar space-between;

Depending on the size of the grid container you might get a strange situation where you should decide if you want to just overflow or ignore the aspect-ratio.

For example if the grid container has width: 300px; height: 300px; everything fits fine. The gutter in columns would be 100px, so it's used for the rows too. 1st row would go from 0px to 50px and 2nd one from 150px to 200px.

Output of previous example

But what happens if you change the size of the grid container to width: 500px; height: 300px;. The gutter in columns would be 300px, but there's no enough room on the block axis if you want to use a 300px gutter too. One option would be to follow the aspect-ratio and overflow (overflow is usual something we don't like), another option would be to ignore the aspect-ratio and just do a regular space-between there (this will be strange as the user is explicitly setting the aspect-ratio).

Possible solutions for the previous example

It'd be nice to gather feedback from web authors about what would be the best option here.

@frivoal
Copy link
Collaborator

frivoal commented Apr 17, 2018

I think overflow / underflow is OK here. If that is not the desired behavior, the author should not set the height of the grid. Depending on the situation, maybe min-height would be more appropriate, or maybe both height and min-height can be auto.

@fantasai
Copy link
Collaborator

@mrego I think overflow is the expected behavior here. It's not much different from having gaps, they're just gaps that are calculated from a justification value on the opposite axis. The use case here is a grid which has a fixed height and scrollbars: you want the items to fit into the horizontal space so you use justification, and you want the gaps to be equal, so you use align-content: 1ar.

@fantasai
Copy link
Collaborator

Switched to using ar units per WG resolution. I also fixed the order of the values so that if we port them to the shorthand, they'll parse clearly. Closing out the issue for now, please file new ones for any issues with the current text!

fergald pushed a commit to fergald/csswg-drafts that referenced this issue May 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants