Add holding features for unspecified platform features

[ddbeck]

This PR contains features that hold compat keys for unspecified platform features. See #1497 (comment) for candidate keys. These are features of last resort for keys that cannot be assigned to a "real" feature (discouraged or otherwise), for lack of a specification.

If you have privileges on this repo, then you're welcome to push additional commits to add keys as you review them. But before you do so, please take a few minutes to confirm that:

• The key lacks a spec_url value in BCD.

• The key has standard_track value set to false in BCD.

• The feature was not formerly part of a spec or explicitly excluded from a specification (i.e., the specification process intentionally favored a standardized alternative). Such keys might be candidate for actual features (Add feature for discouraged import assertions #2565 for an example).

  Good places to find this information include:

  • The BCD key's Git blame view and BCD repo PRs
  • GitHub repos and orgs, such as w3c/csswg-drafts, WHATWG, and TC39.
  • Browser bug trackers (best for keys with single-implementations)

[foolip]

Can we put this in drafts instead, and update our scripts to count keys in drafts as handled? (But excluding auto-updated spec drafts, I think.)

[foolip]

Can't land without this, right?

[ddbeck]

Correct. I've added one with 83a6333.

[ddbeck]

For completeness, I should note that it would be nice to link to https://w3c.github.io/unspecified-web/ but it's pretty unmaintained and covers very little. Maybe creating these features could spur the revival of that "spec."

[ddbeck]

@foolip

Can we put this in drafts instead, and update our scripts to count keys in drafts as handled? (But excluding auto-updated spec drafts, I think.)

We could, though that would require dealing with the existing drafts first (#2632 and #2633).

But this is now in a mergeable state (at least, the tests pass), so it might be easier to review the docs and merge without the drafts detour.

[foolip]

I hesitate to approve because unless we do something special, these features will show up on webstatus.dev and perhaps also caniuse.com, but they're not useful to users of those sites, I think.

@jcscottiii WDYT, do you think it's worth extra effort to avoid showing these features?

[ddbeck]

FWIW, webstatus.dev shows other discouraged features (e.g., https://webstatus.dev/features/import-assertions), which is also less than ideal (at least, for it to show up in a default search). If the discouraged data isn't good enough for consumers to deal with that, then I would favor parking these in drafts.

[captainbrosset]

webstatus.dev should either hide the discouraged features, or highlight them as discouraged. The explorer does this:

See https://web-platform-dx.github.io/web-features-explorer/features/clip/ or https://web-platform-dx.github.io/web-features-explorer/features/with/
The BCD keys that are left for us to map are almost all deprecated keys, so consumers of the data need to be able to deal with these discouraged features, as we're creating more of them now.

@ddbeck should we use the "breaking changes" discussion for this? It's not a breaking change per say, but important enough that we'd want to alert users via the discussion (and maybe send an email to the list too).

[ddbeck]

Yes, we could send out a reminder about it, though I'm not sure who it's affecting right now (webstatus.dev excepted).

There's GoogleChrome/webstatus.dev#1040 for this for webstatus.dev specifically. caniuse doesn't ingest whole (new-to-caniuse) features yet (confirmed this with Alexis yesterday). MDN is already suppressing the Baseline banner on affected pages and Kadir and I working with them to get an Explorer-like banner.

[captainbrosset]

Yes, we could send out a reminder about it, though I'm not sure who it's affecting right now (webstatus.dev excepted).

There might be more consumers of the data which we are unaware of. I tend to think this is the perfect occasion to start using this new discussion thread.

[jcscottiii]

For webstatus.dev, our plan is to implement a banner for discouraged features, mirroring the approach used in the explorer. However, I'm concerned that this PR groups potentially unrelated compat keys into catch-all buckets. This raises questions about whether the 'discouraged' designation is the most appropriate for these unspecified features. I'd lean towards marking them as 'drafts' instead.

If we proceed with the 'discouraged' enumeration, I suggest adding a new flag within the discouraged section. This flag would allow consumers to differentiate between: 1) features where alternatives exist and should be highlighted (e.g import-assertions), and 2) features that should be effectively ignored (e.g. unspecified-css). This distinction is crucial for accurate and helpful presentation to our users.

[ddbeck]

I've gone ahead and moved these into the draft folder, so we won't publish these until we've sorted out a way for consumers to hide these features in particular. (I'd prefer to do that in a separate PR.)

[captainbrosset]

Discussed on the WebDX CG call now.
This came out of the big push to cover all BCD keys. There are a lot of keys that have no specs. So we ended up with keys that can't be mapped to a feature. The suggestion was to do something so we know these keys have been delt with (for stats, and also for tooling to check the Baseline status of a thing that's not in features). Put them into a fake feature. We'd generate a status for them.

Daniel: a bit weird, but still feel positively about it. Consumers would have to filter this out though. Are there things we can do to bring this forward?

Some of the features in here could be real features, marked as discouraged. It would be a good exercise to mint new features out of what's in this PR. And we'd be left with a few oddities.