an alternative to version numbers might be years - e.g. "grid-2022" would refer to CSS Grid as would have been understood in 2022 (or whatever years makes this least ambiguous); when in 202X, most people would understand CSS Grid to include masonry and subgrid (but doesn't include the new fancy supergrid and rotary extensions), we would coin a new grid-202x name?

(that would imply we wouldn't coin the "parent" feature until 202x, which may or may not work well)

I also agree we'll need a parent feature, but I don't really think it matters. At least now, it's a pointless feature to give a name or list on caniuse.com. At some point in the future all of the Grid features might make sense to call just "Grid", but not now.

I think this is a case of how we're going to evolve the feature hierarchy over time. Perhaps right it should be:

• future-grid-group (hidden)
  • grid
  • masonry
  • subgrid

And eventually it will be:

• grid
  • classic-grid (hidden)
  • masonry
  • subgrid

Thanks for the reviews, everyone!

Three comments, one from each of you, ties something interesting together:

I can't come up with another term for the parent group. It feels weird to invent something new

that would imply we wouldn't coin the "parent" feature until 202x, which may or may not work well

it's a pointless feature to give a name or list on caniuse.com

I think these three comments share a common theme: some groups-of-groups are going to feel artificial because they don't (yet) describe something immediately relevant to web developers. Some groups of groups won't have that feeling, but the ones that do are a problem for us.

This suggests a few things to me:

• We could distinguish between descriptive groups, which are recognizable by web developers (whether flat, like subgrid, or nested, perhaps Web Components), and groups that don't really exist except to the extent that other features cast a group-shaped shadow (the grid super group). Rather than proceed immediately with a grid super group, I may continue to fill out non-shadow groups first (with the expectation that we'll soon encounter a group that makes for a good test case). Expect more PRs.

• We should ask consumers like MDN and caniuse what they make of such a distinction. My hypothesis is that the shadow groups have some utility to consumers like MDN and caniuse (e.g., if I'm writing a grid overview, it might be nice to have a high-level table to break out support for classical grid, subgrid, and masonry). But they might not be interested in directly exposing such groups to readers (e.g., a single negative compat indicator for all grid-related features). If that hypothesis is correct, then they'll need a way to tell the two apart. I've opened What do consumers want or expect when it comes to groups of groups? #92 to track this.

• Naming things is hard (and I consider versioning a subset of naming). Far-future grid-with-everything requires us to prognosticate about web developers' mental model of web technologies years from now. I don't know about you, but I'm bad at predicting the future! By the time we hit 1.0, we should have a mechanism to help consumers of this data gracefully follow the inevitable renames and changes. I've opened Consider handling feature identifier changes or aliases #91 to track this idea.

we should have a mechanism to help consumers of this data gracefully follow the inevitable renames and changes

Totally agree with this.