The Level 1 CSS Grid specification has now landed in Firefox and Chrome, and is expected to ship in the next version of Safari. Those implementations cover the majority of the level one spec and are very interoperable. There are a few differences, mostly due to parts of the specification that are still being worked on even as grid ships, however the browsers implement the majority of the spec in the same way.
The standout missing element is of course subgrid. No browser has an implementation of subgrid as yet, and one implementor has serious concerns about the revised spec for this feature that was edited into the Level 1 specification last year.
The revised specification was a simplified version of the feature detailed in previous drafts of the spec. The key difference was that in the revised version, a subgrid would be locked to two dimensions. Therefore you would need to know in advance how many rows AND columns that you needed in the subgrid, and account for them in the parent grid. I think a common use case would be wanting the nested items to use the column tracks, but maintain rows according to whatever content was flowed into that area. At the time, I was keen to explore a revised version as I believed (and still do) that subgrid is an important piece of being able to create robust layout on the web. I also feel it is important in that it can remove the temptation to flatten markup to enable items to be more easily grid items. However I had some doubts about this being locked to two dimensions then, and as time has gone by, and I have started to see more author use cases, that feeling has increased.
Why move the feature to level 2?
In the CSS WG telecon yesterday, the group discussed and then voted on moving the subgrid feature to Level 2 of the specification. I voted for this move, despite being as keen as ever to see this implemented.
Whether subgrid stays in the Level 1 specification or is moved, is probably academic in terms of it being implemented. Moving it however enables the implementations to complete on all the features of Level 1, which would be a positive thing for web developers – to know that everything in the spec is available. It also hopefully signals that we would like more feedback, and ideas from browser implementors and authors. What is required from this feature? Does the revised proposal make sense, or would it leave out a whole host of use cases?
What now?
I do not want to see this feature shuffled out of view. I still believe it is incredibly important for grid. I would like to double down on efforts to collect real use cases for the feature from web developers, now that people are starting to build real things with grid as opposed to demos. I can then bring those to the discussions that browser implementors and the spec editors are having around the feature.
How to provide a use case
What makes for a good use case for the feature? It doesn’t need to be anything complicated.
If you are building things with grid and think, “it would be very handy if these child elements of a grid item could use the parent grid”. That is where you want subgrid.
You may be able to solve that issue with display: contents which is available in Firefox and in development in Chrome. Leaving browser support out of the equation (we’re talking about something that doesn’t exist anyway) would display: contents solve your problem?
If display: contents doesn’t solve the issue, or would only partially solve the issue, or solve it by introducing a new one this is probably a use case for subgrid. Would a subgrid locked to two dimensions work? Or do you need to ability to line things up in one dimension (column or row) and then have the content dictate the tracks in the other dimension?
I would love to see any of these use cases. Post then with code if possible (or a drawing) over at my CSS Grid AMA, like this one. Collecting use cases means we can test the existing proposal, or any future ones, against real requirements.