[css-grid-2] `subgrid` specified on grid-template-rows/columns and computed value for standalone axis

[KurtCattiSchmidt]

"If there is no parent grid, this value is equivalent to the initial value, none, and the grid container is not a subgrid."

https://www.w3.org/TR/css-grid-2/#subgrid-listing

Does this also apply to the computed value for grid-template-rows/columns? That is my understanding, but no implementations are following this. I have a PR open to address this in Chromium (here), but I wanted to run this by the working group to make sure I'm not missing anything.

To clarify, if an item has display: grid, and grid-template-columns is set to a value containing subgrid, but the item is not the child of a parent grid (and thus not a subgrid, but is a valid grid), should the computed value of grid-template-columns be none?

The variations of this are clear - if it's not display: grid, the computed value is the specified subgrid value as specified (not expanding repeaters, etc.), and if it is a valid subgrid, the computed value expands repeaters and outputs line names and not sizes. These are both in agreement across implementations.

Here's what I have observed for this scenario:

Blink: Crash (fixed in the above PR to compute to none)
Gecko: Reports tracks sizes without line names, as if it's a standalone grid (but missing line names). I can see how this behaves as if it's none by ignoring the line names, but it seems a bit strange.
WebKit: Returns the specified value as if it were not a grid container at all. This seems reasonable to me, but doesn't follow the above referenced line in the spec.

[KurtCattiSchmidt]

Note that the above PR adds an official test case for this scenario that only passes in Chromium with my changes. I'm happy to update the behavior in Chromium and the test case if I'm reading this incorrectly.

[Loirooriol]

See #6165: no, it should not affect the computed value. But I think it should still affect the resolved value that you get in getComputedStyle. You can check the actual computed value by using inheritance: testcase.

[KurtCattiSchmidt]

Interesting, looks like we both had the same question! My reading of this is that Firefox is indeed correct here, do you agree? In other words, the computed value is as if it's a standalone grid (which it is), not the subgrid computed value (which only reports line names and not track sizes), and line names specified in the ignored "subgrid" grid-template-columns value are dropped, as the entire grid-template-columns definition behaves as if it's none. Does that sound right? If so, I'll update the behavior and test case in Chromium to match this.

This also makes me think of another edge case, which is that the line names in this invalid subgrid definition (that behaves as none) should not inherit to child subgrids, right? I'll add another test for that.

[Loirooriol]

Yes, Firefox seems right. If the specified value has subgrid, then https://drafts.csswg.org/css-grid/#computed-track-list

The computed track list of a subgrid axis is the subgrid keyword followed by a list of line name sets and computed repeat notations representing the line names specified for that axis.

If the element is a grid, this may end up behaving as none (standalone axis) or stay as a subgridded axis.

When using getComputedStyle, then https://drafts.csswg.org/css-grid/#resolved-track-list applies, so e.g. when subgrid behaves as none and produces a standalone axis, we get the used track sizes.

[KurtCattiSchmidt]

Thank you for clarifying. I will update the implementation in Chromium as well as the test case to match Firefox, as the above referenced PR has landed.

The corollary to this is that if it behaves as none, that line names defined there should be dropped. Firefox is doing this with the computed style values, and they should also not be inherited into child subgrids. I haven't tested this yet, but I think that Chromium will need some additional work to drop these from both computed style and inheritance. I'll definitely add a test case for that along with the other referenced changes.

[KurtCattiSchmidt]

I think it's reasonable to mark this issue as closed from the working group perspective (although there's still some work do be done on my end for the Chromium implementation and tests). Closing out this issue.

[KurtCattiSchmidt]

The commits listed above are for the Chromium behavior to match your reply above @Loirooriol. The test was also updated to reflect this, and Blink and Gecko are now in agreement with the above patch.