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
Comments
Just to summarize, the example is
I think there are two possible solutions here:
|
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. |
Agenda+ to request some ideas. We should fix this by the L2 FPWD. |
The Working Group just discussed 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) |
Proposal... Name: <number>
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.
This next example is the same as the previous, except that the ratio between row and column gaps is φ:
... Thoughts? |
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 ? |
How this new value will be used in the place-content shorthand ? Some possibly ambiguous expressions that came to my mind:
Shouldn't forbid this new value from the place-content shorthand's syntax ? |
Another issue that I'd like to note down here is how we want to deal with the different scenarios producing overflow:
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. |
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 ? |
The Working Group just discussed
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. |
The Working Group just discussed
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 |
I was talking about some of the issues described by @javifernandez with @rachelandrew past week. 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 But what happens if you change the size of the grid container to It'd be nice to gather feedback from web authors about what would be the best option here. |
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. |
@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 |
…ad of <<number>> per WG resolution. #1116
Switched to using |
…ad of <<number>> per WG resolution. w3c#1116
[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.
The text was updated successfully, but these errors were encountered: