Join GitHub today
[css-grid] Percentages gaps and intrinsic size #509
There were some discussion on the TPAC but we didn't arrive any conclusion regarding how percentages should be resolved during intrinsic size computation.
Basically we've some different options that I'll try to explain here and also compare with what we've on regular blocks and tables.
1. Percentage resolution for width on regular blocks
Let's start by the most basic stuff, how a percentage is resolved in a simple case like this:
<div style="float: left; border: thick solid magenta;"> <div style="width: 150%; background: cyan; font: 25px/1 Ahem;">XX X</div> </div>
Note: Ahem is a font commonly used for browser testing. Here we know that the size of the element will be 100px, due each char "X" and space has a 25px width.
The behavior here is the same in any browser, and the 150% is resolved against the intrinsic size of the element (100px), in this case the result is 150px.
2. Percentage resolution for margins
However the discussion is now was triggered by the difference between Firefox and the rest of browsers resolving percentage on padding/border/margin (see issue #347 ).
A very simple example showcasing this:
<div style="float: left; border: thick solid magenta;"> <div style="margin-left: 20%; font: 25px/1 Ahem;">XXXX</div> </div>
Here Firefox does something different to the rest of the browsers in order to resolve the 20% margin. It uses the 100px intrinsic size, to compute back the percentages, so the final size of the container is 125px and the 20% is resolved to 25px. To calculate the size the formula is basically: 100px / (1 - 0.2). The really good thing is that the element doesn't overflow the container.
The rest of the browsers resolve the 20% percentage against the intrinsic size of the element 100px. So they consider it as 20px. And the element overflows.
3. Percentage resolution for grid tracks
So now the question is what to do on grid tracks and gutters regarding how to resolve percentages on these situations.
Let's start by percentage tracks:
<div style="display: inline-grid; grid: 100px / 50% 100px; border: thick solid magenta;"> <div style="background: cyan;"></div> <div style="background: yellow;"></div> </div>
Right now all the implementations have the same behavior here. The 50% track is resolved against the intrisic size of the grid container, which is 100px (the fixed track). So the percentage track has a 50px width. And the tracks overflow the grid container.
The idea was to check if we could do something similar to what Firefox does for margins on a regular block or not in the grid cases. If we follow that idea in this case the percentage track would be resolved to 100px and the the grid container will have 200px width so the tracks won't overflow.
This is actually the same the behavior of tables in all browsers:
<div style="display: table; border: thick solid magenta;"> <div style="display: table-cell; width: 50%; height: 100px; background: cyan;"></div> <div style="display: table-cell; width: 100px; height: 100px; background: yellow;"></div> </div>
However when you add content to the table, the behavior is different as the 2nd column grows more than the 100px width we set:
<div style="display: table; font: 25px/1 Ahem; border: thick solid magenta;"> <div style="display: table-cell; width: 50%; height: 100px; background: cyan;">XXXXXX</div> <div style="display: table-cell; width: 100px; height: 100px; background: yellow;"></div> </div>
As you can see the first column is 150px (due to the content) and the 2nd one is grown up to 150px, in order that the the intrinsic size of the table is 300px and the 50% of the first track is matches the 50% computation.
Probably this doesn't make sense if we think on grid layout tracks, it'd be weird that a fixed track grows over their specific size. If we do a similar example with grid:
<div style="display: inline-grid; grid: 100px / 50% 100px; font: 25px/1 Ahem; border: thick solid magenta;"> <div style="background: cyan;">XXXXXX</div> <div style="background: yellow; opacity: 0.8;"></div> </div>
The percentage is resolved against the intrinsic size, which in this case is 150px (due to the contents on the first column) + 100px = 250px. So the 50% of the column is resolved as 125px (the content would overflow), and the 2nd column keeps being 100px.
And I believe the same would happen for both tracks and gutters. As a grid gap is not more than a fixed track with the given size from the track sizing algorithm point of view, but it can have contents if an item is spanning several tracks. So we might have similar issues regarding back computing percentage gaps.
I think the options we've right now are:
IMHO, I'd discard option C) due to the issues explained before when a percentage track has contents.
What do you think? Opinions, feedback, corrections, etc. are welcomed.
I don't have a overwhelming preference. On the one hand, having something that looks broken will help authors know they should rethink their code. On the other hand, I can see this coming up in real world usecases, and having Grid return a broken result is a bad idea. It would be better for it to resolve in some kind of useable way.
Here's the real world usecase where I think this might come up. An author creates a 'media block' component in their new style guide. It uses Grid to layout a photo, a headline, and a teaser paragraph. They defined things in percents because Grid is new to them, and they aren't used to the new options. Then they take that component's code and use it in many places around the site. It works fine in the legacy full-page layout (that has a fixed overall fixed-size columns). It works fine in every use case, for months. And then they redo their full-page layout using Grid, and this component is dropped into an auto-sized track, on a parent Grid. Suddenly it breaks. And the author doesn't know why.
Maybe we want the % track to resolve to zero if it's empty. Basically — have it always act like it's
Maybe we want the % track to act like it's
Of Manuel’s three options, I have a slight preference for A. This might be due to my having gotten very used to the idea that tracks can spill out of grid containers. Maybe a little too used to the idea, honestly. But it’s straightforward to explain and understand, and fits with what authors generally expect from regular blocks.
I greatly dislike B—assuming any percentage to be zero will lead to deeply unintuitive results, effectively indistinguishable from bugs to the average author.
I kind of like C, given that it taps into long-extant behavior. There are already descriptions of how to resolve similar situations in the table-layout module of CSS, and they could be leveraged. I’m just not sure they’re the best behavior for grids, so I lean away from C a bit.
But I think Jen’s onto something with treating these situations as if they were a species of
@fantasai: Does that mean you want the grid container to overflow its parent, in preference to the grid’s contents overflowing the grid container? That would upend the way blocks are usually treated: given an
referenced this issue
Sep 21, 2016
I also think there might be something to setting the track sizes to
That's not at all the issue here. The analogy is a percentage-sized child inside an auto-sized (shrinkwrapped) float. That is, the percentage child is resolved against the container, and the container is resolved against the size of the child. (If the grid is sized to fill its container, then that size is definite and we can resolve the percentage no problem.)
I've been thinking about this and don't have a strong preference. It makes most sense to me that they would be set to
I'd like to state that making gaps work as auto tracks will complicate a lot the implementation of the track sizing algorithm, something that we should not do being so close to CR IMHO. Fixed size gaps are easy to accommodate in the algorithm machinery because they only involve reducing the available space to distribute, but making them content-sized will require major changes in the algorithm.
Yeah I was thinking on this the whole night and I believe we should just keep the current implementation.
Probably the spec needs to be updated:
Here's my proposal for percentages in intrinsic sizing:
I think the reasoning that
Here's a testcase with some examples (the two boxes at the end are grids, the first is a flexbox and the second is a block with percentage padding for comparison):
I'm not sure I like this approach, as I've shown in the previous example 2 tracks of 10% will have different sizes; that seems quite strange to me.
If an item spans several tracks, the item is somehow inside the gap. The spec says: "For the purpose of track sizing, each gutter is essentially treated as an extra, empty track of the specified size."
Of course, it depends on how you resolve the percentage of the gap for the gutter, but if we use
IMHO, we should try to make percentage tracks the very same than percentage gaps. So it'd be the same to use
They're not defined that way; there's a non-normative summary sentence (using the word "essentially", and another one using "as if") making a general statement that they operate as if they're empty. But there's nothing normative stating that; as the spec is written, "treat as
However, we discussed this at the F2F (resolution) and resolved that percentages are 0 for determining intrinsic width, but still resolve at used-value time, giving us the Chrome behavior (where the yellow track overflows the grid container, in Manuel's example).
Hum, I didn't follow the "essentially" discussion but I just wanted to correct that we did not resolve that percentages "resolve to 0 for intrinsic width computation" but that "percentages are ignored for the purpose of comping the intrinsic width, but resolve at layout time". Those two things are different.
then narrowed down to
Though, yes, in the case of gutters, since there is no content inside them to give them an intrinsic width, that means that percentages act like if they were in actuality nullified during that computation. For another track that has content directly inside, the result would vary.
For widths that would cause that a percentage track and a percentage gap are not equivalent (which probably is not bad).
<div style="display: inline-grid; font: 10px/1 Ahem; border: dotted; grid-template-columns: 50px 20% 50px;"> <div style="grid-column: 1;">X</div> <div style="grid-column: 3;">X</div> <div style="grid-column: 1 / span 3;">XXXXXXXXXXXXXXX</div> </div>
During intrinsic size computation, the
Then if we've a similar example but using gaps:
<div style="display: inline-grid; font: 10px/1 Ahem; border: dotted; grid-template-columns: 50px 50px; grid-gap: 20%;"> <div style="grid-column: 1;">X</div> <div style="grid-column: 2;">X</div> <div style="grid-column: 1 / span 2;">XXXXXXXXXXXXXXX</div> </div>
During intrinsic size computation, the percentage track is treated as
If we want to have the same output in both cases, a possible solution would be to treat percentage gaps as an
I've ended up here again while doing some poking around at interop issues with percentage sizing of gaps. Currently there seems to be decent interop on
When I look at
Both seem to agree when the grid has a fixed height. Quick demo here: https://codepen.io/rachelandrew/pen/xLZbMm
I was going to raise an issue with Firefox, but I don't know if this was ever officially resolved on here.
I know this is still marked as at-risk in the spec, however an author pointed out a use case for percentage gaps that I hadn't considered. They enable the use of a grid layout component in a layout that uses a flexbox or float based grid, which relies on percentages for responsive spacing.
The Working Group just discussed
The full IRC log of that discussion<dael> Topic: Percentages gaps and intrinsic size
<fantasai> s/contribute to fr resolution/contribute to fr track minimums/
<dael> github: https://github.com/w3c/csswg-drafts/issues/509
<dael> Rossen_: Let me paste the time stamp instead of the whole issue
<dael> Rossen_: rego has it
<dael> rego: I reopened it.
<dael> rego: All browsers now support % in column gap in multi column
<dael> rego: All of them are interop. But they're not following new text in spec. Chrome and webkit we don't see an easy way to follow for width so I suggest we change the text to says something like % resolves to 0 when resolved against the base size. Something like the indefinite size is what we should say because the logical width is not indefinite.
<dael> rego: That causes overflow in some cases but I don't think there's a way to do it better and changing spec text would make it match impl.
<dael> fantasai: If we go back to the options before there was option b which was contribute 0 resolve as 0. Igalia is saying we don't know when to resolve if it's at 0 or not because that info isn't part of what's given to grid when it's doing layout.
<dael> fantasai: It's easier for impl if they just continue tracking or continue tracking into the container and therefore the percent resolves.
<fantasai> s/or continue tracking into the container/continue tracking just the information they have already, i.e. the size of the container/
<dael> Rossen_: I can't speak to other impl, in our grid impl we know if we're doing layout for sizing and measuing the content vs sizing when we're not shrink to fit. From that PoV I don't think we have anything in the spec that prevents a impl from passing this info
<dael> Rossen_: Looking at current interop around this....based on the codepen from the issue seemed like we all agree on behavior of grid.
<fantasai> s/that info/information on whether the current size of the container was a content-based size/
<dael> Rossen_: rego what I hear is once we go down...if we change resolution from b to d, contribute 0 resolve as 0, we minimize amount of potential overflow, but also drop ability to have % column gaps. Last time we discussed the one constant feedback from webdev was they don't want to drop the gap. It's more intutive if you see overflow and go and fix it rather then add values and have no effect.
<dael> Rossen_: I'm not sure we're driving toward an ergonomic.
<dael> fantasai: Previous resolution was b and we're proposing switch to d.
<dael> Rossen_: In that case I agree and misunderstood the proposal.
<fantasai> s/ergonomic/ergonomic solution/
<dael> rego: It would be more like f.
<dael> rego: It would be like when grid resolves % for width and height in regular blocks they're different so same here.
<dael> Rossen_: Okay, I'm with you.
<dael> Rossen_: Other opinions on this?
<dael> fantasai: Proposal is to resolved the % in column gaps but not row gaps?
<dael> rego: Yes. To resolve the % when the size is definite, but not when indefinite. width is only indefinite for intrinsic sizes.
<dael> fantasai: That gets to the point where we wanted symmetry and we don't have that.
<dael> Rossen_: Same concern. Only thing that is symmetric is we're talking definite vs indefinite instead of width and height. I wasn't going to object hard, but I'm with fantasai that we want to keep as symmetric as possible. Just because of how flow layout works today more often then not width wiill be definite and height indefinite or vice versa.
<dael> rego: There is the other issue about how % tracks work where they should be symmetric and resolve always. So maybe that's an option here. But no one is supporting the heights for % rows yet. Maybe that's the way to go.
<dael> Rossen_: This is option f?
<dael> rego: Option b I guess.
<dael> rego: Following what we resolved in issue #1921. It's not impl, but we resolved that way in the past.
<dael> Rossen_: Going through 1921 resolution it makes sense, but impl have to catch up. Once we do we'll have symmetric behavior. Then we need to do same thing for gaps. That would be behavior b.
<dael> rego: For multi column it's what we're doing right now. We're always resolving the % because multi col only has column gap.
<dael> Rossen_: Right but for grid it's both column and row.
<dael> dbaron: I'm not an expert on grid, but I felt like I liked the original proposal from rego a bit more. There's a lot of stuff where width and height just doesn't work the same way. Things that happen in intrinsic width pass shouldn't effect layout pass.
<dael> Rossen_: I wouldn't disagree in general, but I would slightly disagree in teh case of grid because we've been trying for as symmetric as possible. We had a fully symmetric implementation and that fell through. It will require more passes to make symmetry stable, but it's possible.
<dael> Rossen_: Let's try and move forward.
<dael> Rossen_: Proposal in the issue was we resolve to have a contribute 0 and resolve as percentage
<dael> Rossen_: Correct?
<dael> rego: That's not what's in the issue, but yeah. That's the new proposal to keep symmetric behavior following the tracks resolution.
<dael> Rossen_: Which is option B.
<dael> Rossen_: Any opinions or objections?
<dael> RESOLVED: Take option B (contribute 0 and resolve as percentage for column and row gaps)
So, just to make sure I understand the resolution above correctly, the resolution is that gaps resolves percentages the same as was decided for margin/padding in #347, except that the percentage basis for
Also, since there is some discussion of percentage track sizes in general in this issue - those continue to "behave as auto" when the percentage base is indefinite as before, right?
I understand the same thing regarding that.
No, they would behave as auto but then they'll be resolved during layout.
With the resolution here from yesterday, gaps would be working pretty similar to tracks.
So for gaps if we have this example:
<div style="display: inline-grid; border: 10px dotted red; grid-template-columns: auto auto; grid-gap: 25%; font: 50px/1 Ahem;"> <div style="grid-column: 1; background: magenta;">XÉpp</div> <div style="grid-column: 2; background: cyan;">XÉpp</div> <div style="grid-column: 1 / 3; background: yellow;">XÉpp</div> </div>
It'll have a column gap of 100px and a row gap of 25px. While the size of the grid container will be 400px width and 100px height.
Right, that's what I meant with "when the percentage base is indefinite" qualification
Interesting. I wasn't aware that was the intention of #1921.