Clarifying the caniuse key

[autonome]

The contribution guide says the caniuse is optional, but nothing else really.

We should explain:

• why it's there
• what it is (or could be) used for
• reasons to add it or not

[ddbeck]

I need to turn this into a PR but…

• The caniuse key says that this feature is (approximately) the same as the corresponding caniuse feature.
• Use the caniuse key when:
  • You want the headline status for the feature to appear on caniuse.
  • The high-level feature is roughly equivalent to the caniuse feature(s) or a strict superset of the caniuse feature(s), subject to the caveats below.
• Don't use the caniuse key when:
  • The caniuse key is merely related (e.g., in grid.yml, don't set caniuse: css-subgrid) or not at all related.
  • The headline status (not the overall, not per-key status) would not be accurate with respect to the table on caniuse (e.g., caniuse says a feature is unsupported in a core browser set browser, but the web-features status is Baseline).
  • The status's first-supported version number differs from caniuse's by more than one year before 2020 or at all from 2020. This means there's a major disagreement—and a likely error—in BCD or caniuse's data.
• Additional notes:

  • Use compute_from to improve the correspondence of a feature's headline status with respect to the caniuse feature.

    But don't forget to use your judgement! Caniuse isn't perfect. Don't use compute_from in a way that would not make sense if the corresponding caniuse key didn't exist (e.g., pins support to before support for some essential key in the feature). In such situations, it's better to comment out the caniuse and make a TODO comment or open an issue about why you did it.

  • If you see a <1 year pre-2020 discrepancy between caniuse and a computed status, make a note of it in Historical investigations: caniuse and BCD mismatches #1499.