Demo: compat key sets authoring (successor to compute_from)

[ddbeck]

This PR demonstrates part of the "aspects" project: naming sets of compat keys within features. This can help us make more checks on a key's membership in a feature and assign meaning (if any) that a key should have with respect to the feature's status.

As a refresher, I'm proposing three sets of keys:

• A strictest set, here called core_name_tbc. These keys are used to compute the headline status for the feature and gives the feature's "birthday." It's equivalent to the set of keys given by a compat_features array without a compute_from, in the existing authoring schema.
• A semi-relaxed set, here called modifiers_name_tbc. These keys will be required to have the same status level or better as the keys in the strictest set (or the status level given by a status override). For example, if a feature is Baseline high overall, then these keys must all be Baseline high, even if the dates or specific version numbers do not match the headline status.
• A fully-relaxed set, here called incidentals_name_tbc. These keys do not contribute to the status of the feature and will not be checked against the status of the feature. It's for keys that are related but for various reasons cannot be used to enforce a status (e.g., data errors, conflicts with caniuse, etc.). Over time, we'd likely fix or move most (though not all) of these keys.

I've done a self-review on this PR to call attention to various details here. In general, you'll find that changes fall into two buckets:

• Demonstrating applications for new authoring, particularly in opening the door to new linting and validation.
• Algorithmically sorting the keys into sets happens to better expose information about features as they already exist. These exposures suggest ways we might improve the way we've defined features or contribute changes upstream, but this authoring makes it more obvious (and easier to find such features where work is needed).

Head to the changes tab for a guided tour.

[ddbeck]

The bulk of these changes will merely expose certain issues in a more findable way. Here, you can see more easily that there should be a separate feature minted. It happens that this is already in progress with #2947.

[ddbeck]

Here's the first new application for these sets: linting our existing overrides. In autofocus, we've overridden the status to align with caniuse. By assigning the keys to the modifiers_name_tbc set, I'm declaring that all of the keys must meet the level given by the status override.

(We could have an implicit rule that a status override implies that a regular compat_features array is the modifiers_name_tbc set, but this seems too magical to me.)

[ddbeck]

Here's another exposure: key-sharing opportunities. Here we have a key that should probably exist on two features: backdrop and dialog. But the influence each of the key ought to have on the status differ, depending on the feature.

[ddbeck]

Here's an application: alignment with caniuse. Two keys are excluded from the birthday setting here, but we can now enforce that the remaining keys should be supported in the same set of browsers as the birthday set of keys.

That said, in this case (given the negative standards positions), we could probably eliminate the compute_from, if we coordinated with caniuse.

[ddbeck]

Here's another exposure: iffy upstream data. css.properties.border-radius.percentage is probably incorrect. But there's also an application here: we can accept the status level of this key and validate it against the headline status, without taking action on the upstream data immediately.

Later, we can ratchet this key into higher expectations, if and when we fix the upstream data.

[ddbeck]

This demonstrates a good application for incidentals_name_tbc: associating a key with the most-relevant feature, even though that key cannot contribute to the headline status.

In this case, api.Worker.Worker.mime_checks isn't a "feature" that a developer can use, but it is relevant restriction that developers will probably want to respect going forward.

See link-selectors for a closely-related situation.

[ddbeck]

Here's another application: ignoring data we can't really trust.

It turns out that I'm the original author of the majority of the hyphens.language_* data… almost ten years ago, when I migrated it from the MDN wiki. 😭 I do not really trust that this data is up-to-date (I'm not even sure it was terribly accurate at the time).

There's a subset here I do trust (this core_name_tbc set), but the rest… well, the one thing I can say here definitively if that these keys are related to the hyphens feature. So we might as well make that relationship explicit (and eventually burndown the incidentals list).

[ddbeck]

Here's another application: ignoring very minor issues.

There's a very poor case for breaking up link-rel-preload over as="track" support. The way I see it, the lack of support for as="track" is one browser's minor bug. Instead of making the platform seem much more complicated than it is by breaking this feature into 3 to 6 features, let's overlook this one key.

[ddbeck]

Here's another application: capturing behavior evolution for reverse features, where the platform took abilities away from developers.

In this case, these keys do not represent a "feature" at all. Instead, they represent a privacy limitation and a way this feature interacts with another feature (the <link> element), or rather how they do not interact with each other. It would be silly to mint a feature for "Not selecting <link> link elements with :link, so modifiers_name_tbc` lets us sidestep doing something silly.

[ddbeck]

The last one here helps queue up the future by exposing candidates for (retroactive) feature merging. Once we implement feature merging, the reversed attribute might make sense as a separate feature that has merged into list-elements. Here's it's exposed as a possibility that we might author later.