Allow non-spec links to be provided for non-standard features

[captainbrosset]

As we head into a new phase of the project where we focus more on bleeding-edge features, we'll very frequently run into a case where features only have early explainers, and no specs.

Currently, the way to deal with this is to create an exception and document when we ought to remove the exception, in this file:

web-features/scripts/specs.ts

Lines 23 to 27 in fe74fdd

	const defaultAllowlist: allowlistItem[] = [
	// [
	// "https://example.com/spec/",
	// "Allowed because…. Remove this exception when https://example.com/org/repo/pull/1234 merges."
	// ]

This doesn't seem very scalable as we start thinking more about an ideal workflow for early features that are not yet standardized, and don't have specs.

[jamesnw]

The spec link is just part of a larger question around bleeding-edge features.

My thought is that we should handle this similar to discouraged, and add something like this-

future:
  documentation: [link to explainer, whatever is relevant]

Features with a future could have looser restrictions, including not validating the spec key.

The ideal flow would be a feature would get assigned an ID so that it could be referred to from the <baseline-status> widget and elsewhere, and then once there are BCD keys available, we would add those. When any of those BCD keys are released in a browser without a flag, we could remove the future key.

We would still need to account for cases where features are renamed before implementation, and would want to communicate that the future web-feature ids are less stable.

Some other features/requests for things that aren't ready to be a feature yet (or weren't a feature when opened)-

• Add new contrast-color feature #2304
• Early customizable select feature #2301
• CSS :open pseudo-class #2414
• Remove image-function but reserve its ID for future use #2341
• Remove target-within but reserve its ID for future use #2339
• Add Error.isError #2440
• Update Masonry's description when the CSSWG resolves the "just grid" vs. new display type question #2045
• Add @container scroll-state() queries #2450
• Snapevents #1522
• View Transition Classes #1491
• View Transitions Types #1409

#1778 is also related towards solving this and #1896 has a different angle.

[captainbrosset]

The WebDX CG discussed about this issue today, see minutes here.

Some key points from that disucssion:

• We'll need housekeeping tooling to alert us of when an early feature either doesn't go anywhere (and needs to be removed), or graduates to a standard feature with a spec (which would require us to update the feature with the new spec URL).
• Early features are likely to be renamed, we'd need to be able to do this without necessarily breaking IDs or publishing a new major version.
• browser-specs has the same problem. Relying on browser-specs to alert us of changes seems good, although it moves the problem, doesn't solve it.
• Feature names and designs tend to change more than we think. So this is definitely a problem we need a solution for.

[captainbrosset]

As time passes, I'm constantly reminded of new features that our repo simply doesn't have because they don't yet have a spec or set of BCD keys.

My opinion here is that, yes there are problems to be solved, but I don't think we should have to be blocked from adding these early features to the repo. The problems to be solved are about renaming, graduating, merging, and deleting early features.

I believe we can solve those problems without having to hold back authors from adding features in the meantime. Practically speaking, this means that I would actually prefer if we could merge PRs like #2301 or #2592 now. In fact, merging (a few of) these early PRs would act as a forcing function for us.