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 auto.

Maybe we want the % track to act like it's minmax(backcomputethingy, auto) — where it acts like auto if the content is making it grow beyond the competed size. But if there's not that much content / is no content, then it acts like the examples where the size is computed based on the other sizes. Basically giving us both of these, depending on whether or not there is content.

The other option we discussed as making the percentages behave as auto if they are specified as resolving against an indefinite size (i.e. one that is auto/or *-content). That would avoid overflow by ignoring the percentage entirely.

(FWIW, I don't have a strong opinion on this except that an auto-sized thing should not have its contents overflow.)

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 minmax() values. The trick is picking the right minimum and maximum values. Jen’s values might be right, or there might be better; I don’t know.

(FWIW, I don't have a strong opinion on this except that an auto-sized thing should not have its contents overflow.)

@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 auto-width div containing a very wide image, the div’s width is controlled by its parent’s width, and the image inside it spills out. Are you saying given a similar case, except with a very wide grid track, the grid container should spill out of its parent in order to contain the grid track?

I also think there might be something to setting the track sizes to auto. Which would make them the content size when there's content, and make them collapse to zero when they are empty. Which it seems is better than letting things overflow. If an author wants them to not be zero, they'll likely start trying to figure out why they are zero — and then realize, oh, % of unknown = oh, zero, ok. It makes sense. Makes more sense than random sizes that are too big and cause overflow.

Does that mean you want the grid container to overflow its parent, in preference to the grid’s contents overflowing the grid container?

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.)

@fantasai: Ah, I see. I took your statement to be generic, not contextually narrowed. My apologies.

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 auto, as described by Jen above, and that was my first thought when I read the initial Issue - prior to seeing the subsequent comments - that they could just set set to auto.

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.

well that sounds like a good reason not to do it given lack of strong preferences. I'd probably lean towards suggestion A of the other suggestions.

Yeah I was thinking on this the whole night and I believe we should just keep the current implementation.
I've found some very weird issues, if a grid-row-gap: 10% would be treated as auto we could end up having gaps of different sizes.
An example to represent it with percentage tracks in a grid with grid-template-rows: 100px 10% 100px 10% 100px.

• One item spanning the first 3 rows with a content of 300px height, the 10% of the 2nd row ends up being 100px.
• Another item spanning the last 3 rows, with a content of 250px height, the 10% of the 4th row ends up being 50px.

Probably the spec needs to be updated:

1. The percentage resolution should be done exactly as it was before (like in regular blocks).
2. We should explicitly say that percentage gaps are resolved as 0px when the height is indefinite (for widths they'll behave like regular blocks).

As @mrego perfectly explained that would lead to gaps with different sizes, a.k.a. something that is not gaps. Authors wanting such a behavior could always use auto tracks.

I begin to understand a little bit why the WG never permitted percentage widths for borders. Kind of tempting to do the same here…