-
Notifications
You must be signed in to change notification settings - Fork 195
Description
Right now, if you want to add a feature before its specification has merged into a spec known to browser-specs, then you must add an exception to specs.ts. It's annoying. I'm proposing an alternative authoring model.
A proposal field in a .yml file would be an alias for spec that bypasses the normal spec URL validation. It would allow (almost any) parseable URL, but guidelines would require stipulate that authors must use a URL in the following order of preference:
- A PR against an actual spec known to
browser-specs - Any other PR
- Any other URL (e.g., an explainer)
If the proposal URL is a spec known to browser-specs then that's an error (it should be in the spec field).
On build, index.ts would rewrite proposal to spec (so it'd be transparent for consumers).
If we did this, then we'd be able to produce a watch list for features that need "permanent" spec URLs. For PR URLs, we'd be able to monitor the status of PR URLs and warn when they've closed or merged, as suggested in #3452.
Like #2647, we might check non-PR URLs for simple existence.