[css-grid] What happens with grid line names when dropping tracks

[svillar]

The specs mention that when using auto-fit, tracks with empty repetitions are dropped. My question is what happens with the grid line names defined in the repeat() function?

As far as I see it we have 2 options
a. we "collapse" them with other potential line names defined outside the repeat()
b. we remove them as we do with tracks

IMO (a) is not the right thing to do due to several reasons. First of all it seems weird to keep the line names and not the tracks. Secondly, we could lead to having only grid line names and no tracks in a definition (for example, grid-template-rows: [a] repeat(auto-fit,[b] 10px [c]) [d]; assuming there are no items then grid-template-rows will become [a b c d] without tracks which is invalid BTW). And last but not least I really don't see any use case for that.

So my proposal is that the spec explicitly mentions (b).

WDYT?

[FremyCompany]

LGTM.

[MatsPalmgren]

I'm not sure what you mean by "will become".
I'm assuming that you're talking about the resolved value for these properties.
https://drafts.csswg.org/css-grid/#resolved-track-list

When there are zero tracks Firefox returns 'none' as the resolved value.
Other than that edge case, we essentially merge the line names with the names on both sides of the dropped track and then remove any duplicates. So for the example you give, "[a] repeat(auto-fit,[b] 10px [c]) [d]", the resolved value is "[a b] 10px [c d]" when there is one item, the resolved value is "[a b] 10px [c b] 10px [c d]" when there are two items etc.

I think this is the result you're suggesting, right?

[tabatkins]

On Wed, Jun 8, 2016 at 12:29 PM, Mats Palmgren notifications@github.com wrote:

I'm not sure what you mean by "will become".
I'm assuming that you're talking about the resolved value for these properties.
https://drafts.csswg.org/css-grid/#resolved-track-list

When there are zero tracks Firefox returns 'none' as the resolved value.
Other than that edge case, we essentially merge the line names with the names on both sides of the dropped track and then remove any duplicates. So for the example you give, "[a] repeat(auto-fit,[b] 10px [c]) [d]", the resolved value is "[a b] 10px [c d]" when there is one item, the resolved value is "[a b] 10px [c b] 10px [c d]" when there are two items etc.

I think this is the result you're suggesting, right?

This is what's intended, yes.

There isn't a good description of how to serialize resolved values,
but "none" is a correct serialization of "all the tracks got dropped".
Names are irrelevant at that point. (Technically they can still
affect whether something gets positioned against the sole explicit
line or one of the implicit lines, but come on.)

~TJ

[svillar]

So my intention was completely the opposite. I think that we should drop also the line names as we do for tracks. And I also mean that we shouldn't use them for positioning either. If you try to position items using the grid line names defined inside the repeat(auto-fit) then you have to deal with the risk that some tracks could get dropped. What's the point of keeping them around?

[mrego]

Just to clarify things a new example:
grid-template-columns: 200px repeat(auto-fit, [a] 50px [b]) 100px;

If you have no items, what would be the result using the options by @svillar on the first comment?
a. "Collapse" the lines: grid-template-columns: 200px [a b] 100px;
b. Remove the lines: grid-template-columns: 200px 100px;

BTW I also think that (b) is the best option in this case.

[MatsPalmgren]

And I also mean that we shouldn't use them for positioning either.

That won't work. Dropping empty tracks happens after item placement.

What you suggest implies doing line name resolution and item placement
all over again, which can affect which tracks are empty, so that would
create a circular dependency.

[MatsPalmgren]

a. "Collapse" the lines: grid-template-columns: 200px [a b] 100px;
b. Remove the lines: grid-template-columns: 200px 100px;

To my surprise, we actually do (b) in Rego's example.
I don't feel strongly about which result is correct in this case though.

[svillar]

And I also mean that we shouldn't use them for positioning either.
That won't work. Dropping empty tracks happens after item placement.

Yes sure, I didn't explain myself properly. I was talking about items dynamically inserted before dropping the tracks. As I said I think we should completely forget about tracks and lines. (Obviously adding an item might bring tracks&line-names back for the following items).

In any case my conclusion is that there is not a "right" way to do this, so we better agree on something and do all the same. IMO the less confusing thing is to remove everything. WDYT?

[fantasai]

A third option would be to keep the tracks in the track listing, but force them to be zero-sized and suppress any gutters between adjacent collapsed tracks. This probably gives the most internally-consistent behavior (and would also be the most reasonable behavior for collapsed tracks if we ever handle visibility: collapsed in the future). Thoughts?

[tabatkins]

Your gutter behavior isn't quite right; we need to either (a) have each collapsed track suppress one adjacent gutter (so "real collapsed real" still gets one gutter between the two real tracks, not 2, and "collapsed real collapsed" gets zero gutters), or (b) clarify that gutters only get generated between non-collapsed tracks (in other words, collapsing happens before gutter creation). I like (b) better, personally.

[fantasai]

Since collapsing the tracks instead of deleting them seems to give the most sane behavior, Tab and I think this would be the best thing to spec. We've drafted up some text for it, and would appreciate any thoughts on the result.

We ended up collapsing gutters by specifying that they coincide, because the location of the gutters and the lines can be detected by abspos, so we can't just drop them. If at some point we add explicitly collapsing columns as a feature (e.g. via visibility: collapse), this behavior would be the correct one to have for that as well.

[MatsPalmgren]

So, this change does NOT lead to any changes regarding line name resolution,
item placement or anything else related to layout, right? It also does NOT lead to
any observable changes in the CSSOM, except for the resolved values of
'grid-template-rows' and 'grid-template-columns', right?
https://drafts.csswg.org/css-grid/#resolved-track-list

[fantasai]

Right. As far as we know, this should result only in observable changes to the position of absolutely-positioned elements pinned to the edges of collapsed tracks, and to the resolved track sizes of any collapsed tracks. It means that no lines or tracks are merged in the CSSOM as a result of auto-fit collapsing.

[MatsPalmgren]

Well, I believe this change DO NOT lead to any observable changes to the position of absolutely-positioned elements pinned to the edges of collapsed tracks (formerly dropped tracks). Given the following example, the left edge of the "abs" and "2" boxes should still
be at the same position (100px from content start edge), right?
https://people.mozilla.org/~mpalmgren/tests/grid/grid-abs-pos-in-dropped-track.html

[fantasai]

Yes, that's the goal. Abspos placement should be referencing the same grid lines as in-flow grid placement.

[MatsPalmgren]

Good, then we're on the same page.

[tabatkins]

And this was accepted in the telcon.

[fantasai]

@svillar , can you verify that this issue was resolved to your satisfaction?

[svillar]

@fantasai : Absolutely. Already implemented in Chromium & WebKit BTW 😄