Adding a couple of new css groups and moving a bunch of features under them

[captainbrosset]

We have quite a lot of ungrouped features (see https://web-platform-dx.github.io/web-features-explorer/groups/) and, while I realize we don't yet have a good grasp on what groups should be, I'm proposing to move ungrouped CSS features under the CSS group, and I'm introducing a couple of new groups (units and selectors) for more specific language features.

[captainbrosset]

Thought: grouping features hierarchically is hard because you can do so in multiple ways: as features of a language (e.g. css selectors, css units, css functions, math, etc. are features of the CSS language), or as task-oriented features (e.g. responsive design, honoring user preferences, etc. are groups that can contain multiple features used to achieve those tasks).

Perhaps we should allow the data to be a graph, rather than a tree, and let features belong to multiple groups.
Perhaps we should maintain this graph as a separate data source, which relies on web-feature IDs, just like any other consumer of the package, allowing for multiple grouping to be made and published.

[ddbeck]

cc: @jamesnw This might be relevant to your work in progress or forthcoming.

[ddbeck]

Perhaps we should allow the data to be a graph, rather than a tree, and let features belong to multiple groups.

This is possible already, I think? You can have an array of groups in each feature. We don't have guidelines or linting for this, so it's possible to do slightly odd things (e.g., putting a feature in both css and a child of the css group).

As for which groups to maintain, I think it's helpful to be able for feature authoring to be able to see related features together (and I suspect there's future maintenance use case for assigning reviewers by group)—partly, we can describe features in terms of what features they are not. So this relates a bit to #1708. What groups have utility for feature authoring and which are only interesting or nice to have?

[ddbeck]

Sorry for the noise of multiple comments. Two more thoughts now that I've actually looked at the diff:

• One possible linting strategy for groups: no feature should be in a top-level group if it's also in a descendant of that group (e.g., you can be in css if you're not in another child of css). Perhaps this generalizes to something like: a feature can be its own cousin but it cannot be its own ancestor (i.e., a feature can be in any number of groups as long as none of those groups are parents or grandparents to each other).
• It might be nice to have compat patterns for groups. For example, features with css.* keys ought to warn you when they aren't grouped with css or one of its descendants. This would probably also help with snapshots, since those can be partly(?) generated from specs (cc: @Elchi3).

[jamesnw]

• It might be nice to have compat patterns for groups. For example, features with css.* keys ought to warn you when they aren't grouped with css or one of its descendants.

This could be problematic- see Popover, which has html, api, and css keys. While it could go in both the HTML and CSS groups, I'm wondering if this would just be to meet the requirement, and not because it's a logical grouping?

[jamesnw]

These changes make sense to me!

[ddbeck]

Let's go! Thank you Patrick!