[css-grid] Resolved values of grid-template-rows/columns don't round-trip

[Loirooriol]

According to @fantasai in #4444 (comment),

Roundtripping getComputedStyle() values is probably the most fundamental rule about defining them.

However, grid-template-rows and grid-template-columns don't always round-trip. That's because they set explicit tracks, which start just after the 1st grid line. However, when serialized, they also include implicit tracks, which may exist before the 1st grid line.

gridContainer.style.gridAutoRows = "1px";
gridContainer.style.gridTemplateRows = "2px";
var cs = getComputedStyle(gridContainer);
cs.gridTemplateRows; // "2px"
gridItem.style.gridRow = "auto / 1";
gridContainer.style.gridTemplateRows = cs.gridTemplateRows; // "1px 2px"
gridContainer.style.gridTemplateRows = cs.gridTemplateRows; // "1px 1px 2px"
gridContainer.style.gridTemplateRows = cs.gridTemplateRows; // "1px 1px 1px 2px"
gridContainer.style.gridTemplateRows = cs.gridTemplateRows; // "1px 1px 1px 1px 2px"

On the one hand, knowing the final size of these implicit tracks can be useful. On the other hand, failing to round-trip sucks.

[Loirooriol]

I have been thinking that we may be able to keep leading implicit tracks in the resolved value and also ensure round-tripping. We only need to allow grid-template-rows and grid-template-columns to define explicit tracks before the grid line number 1.

The current basic syntax is

<explicit-track-list> = [ <line-names>? <track-size> ]+ <line-names>?
<line-names>          = '[' <custom-ident>* ']'

Maybe we could change <line-names> to '[' [ <custom-ident>* || 1? ] ']', with the constraint that this 1 can only appear once in the <explicit-track-list>.

This would define that line name to be the number 1. Tracks before that line would belong to the explicit grid, but items wouldn't be able to use integers in grid-row/column to be placed in such tracks (since 0 is invalid and negative integers refer to the end). Items could still reference line names in order to be placed there.

Then resolved values could preserve this 1 line name if it was specified, and otherwise it could be inserted when there are leading implicit tracks. The previous example would become

cs.gridTemplateRows; // "2px"
gridItem.style.gridRow = "auto / 1";
gridContainer.style.gridTemplateRows = cs.gridTemplateRows; // "1px [1] 2px"
gridContainer.style.gridTemplateRows = cs.gridTemplateRows; // "1px [1] 2px"

[tabatkins]

Whoa, that's definitely a bug; I see how the spec can easily be read to say that, but it is absolutely not the intention that the resolved value of those properties includes implicit tracks. That's just something completely different, not in any way a gridTemplateRows/Columns value.

(I believe it was meant to be referring to tracks created by, say, repeat(auto-fit), which aren't explicitly created by the author.)

[Loirooriol]

Oh, the spec seemed pretty clear to me:

https://drafts.csswg.org/css-grid/#resolved-track-list

Every track listed individually, whether implicitly or explicitly created, without using the repeat() notation.

https://drafts.csswg.org/css-grid/#implicit-grids

The grid-template-rows, grid-template-columns, and grid-template-areas properties define a fixed number of tracks that form the explicit grid. When grid items are positioned outside of these bounds, the grid container generates implicit grid tracks

All Chromium, WebKit, Firefox and Edge implemented it this way. There are also various WPT tests that expect this behavior. Not sure if it may be too late to remove implicit tracks from the resolved value, there might be code relying on that.

[tabatkins]

It may be clear to you, but it's definitely not what we meant to write. ^_^ There's absolutely no world in which implicit tracks make any sense whatsoever to show up in the value of properties that solely define the explicit tracks. (Not unless we alter the properties themselves to allow defining implicit tracks, which muddies the water quite a bit...)

I doubt anyone's depending on this, and if they are, uh, too bad I guess? If anything breaks we'll have to go back and see if we can change grid-template-rows/columns as you suggest to allow sizing implicit tracks as well; the current situation is just utterly broken.

[mrego]

Maybe things like DevTools use that information to know the size of the implicit tracks and the number of them.

[tabatkins]

Agenda+ to discuss whatever needs to happen to make the resolved value of grid-template-rows/columns actually be a valid value for grid-template-rows/columns, either:

1. clarify wording to not imply that the implicit grid is serialized as part of the value, going against all implementations
2. add sufficient new features to grid-template-rows/columns to allow them to size implicit tracks too, and change the serialization of the resolved values to use those features, again going against all implementations.

We cannot stick with what we have today, where all implementations agree on serializating g-t-r/c as a value that is not valid for those properties (the serialization is accidentally valid, but as a different g-t-r/c value, not corresponding to the used value that's supposed to be serializing).

Because both possibilities require all implementations to change, and (2) is actually rather complicated and of fairly minimal value I think, I strongly support (1).

[fantasai]

This edit was added in 4646eb1 in response to https://www.w3.org/Bugs/Public/show_bug.cgi?id=16906

It's very clear that including implicit tracks was intended. CC @atanassov

[tabatkins]

Oh jeez, so this dates back to the original MS draft, and we just rewrote it for phrasing correctness without thinking about the round-tripping implications.

Okay so this is still very wrong, and we have to choose either (1) or (2) from my previous comment; the status quo is utterly broken and unusable.

[Loirooriol]

I think being able to define which grid line is the number 1 might have its usecases other than this, e.g. if you have 3 columns with auto min-content max-content but is there is enough space you want to add some spacing before the first column and after the last one. If you use grid-template-columns: 1fr auto min-content max-content 2fr then you have to alter the integer indices in placement properties. You can use grid-auto-columns: 2fr 1fr and place ::before and ::after in implicit tracks, but it looks a bit dirty. grid-template-columns: 1fr [1] auto min-content max-content [-1] 2fr seems easier and more elegant.

However, something like this would probably need some thought and should target css-grid-3 instead of css-grid-1, but for getComputedStyle we need to fix css-grid-1.

So choosing (1) sounds reasonable. But if in the future we end up adding (2), then it will be sad if now we choose (1), because we will be preventing authors from knowing the used size of the implicit tracks.

[tabatkins]

There are a number of things people want to get out of grids that can't be reflected via properties right now, like where a particular item was positioned, etc. Someday we may offer APIs for those.

But sizing implicit tracks is a complicated issue that I don't want to try and define here. Your use-case can be done by just adding padding to the grid container, btw. ^_^