Factor out Deferred Fetch documentation, shows Baseline on Fetch API

[dfabulich]

Description

Factor out Deferred Fetch documentation from the main "Fetch API" page.

Motivation

After this change, we now show a "Baseline: Widely Available" banner on the "Fetch API" page, and a "Baseline: Limited Availability" banner on the "Using Deferred Fetch" page.

Related issues and pull requests

Fixes #43479

[github-actions]

Preview URLs (2 pages)

• /en-US/docs/Web/API/Fetch_API/Using_Deferred_Fetch
• /en-US/docs/Web/API/Fetch_API

[Josh-Cena]

It was explicitly decided that fetchLater should be part of fetch because it's the same spec and reuses the same machinery: #42693 and #42606.

[dfabulich]

My primary goal here is to put a big green "Baseline: Widely Available" banner on https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API.

There's kinda no reasonable way to show a banner on that page when it's documenting a mix of fetch and fetchLater.

Maybe the moral of this story is to just wait until fetchLater reaches baseline (a minimum of three years from now…?) but that feels like a counterintuitive conclusion.

Fetch API is hardly alone in having this issue.

• https://developer.mozilla.org/en-US/docs/Web/API/File_System_API doesn't have a banner, because it's a mix of OPFS (widely available) and File System Access API (limited availability, opposed by WebKit and opposed by Mozilla).
• https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API doesn't have a banner, because it's a mix of classic WebSockets (widely available) and WebSocketStream (experimental, non-standard; obsoleted by WebTransport API)

[Josh-Cena]

But then we don't have a consistent editorial definition of what an "API" is. Currently our definition is more or less "one spec, one API"; the only exceptions I know are HTML and DOM which are split because of how big their scopes are, and some specs that are coalesced into a single API because of how unified their scopes are. Most specs can be extended, and it would be really awkward if each extension has to become its own API just for the sake of preserving the old API's baseline. After all, API groups don't have the concept of "baseline" anyway; only individual interfaces do.

[hamishwillee]

Thanks @dfabulich.

As @Josh-Cena says, we can't have these changes;

• it's all one API, parts of which are broadly supported and parts that are not.
• Using Deferred Fetch is a guide page. Guide pages don't have those API overview sections. They should not, but sometimes do have browser-compat.

The intent is great, but baseline needs to change to fit the docs, not the docs to the baseline.

It would be good is to create an issue in https://github.com/mdn/fred/issues to note that

• if a page has more than one browser compat entry then the compatibility is not shown. I'd argue that it would be useful to be able to note that parts of an API are very stable and parts are not.
• there are pages that might benefit from the banner, such as Using Deferred Fetch, but that should not have browser-compat. It may be they will say "add the compat key but omit the spec and compat sections", or they might say "it isn't an overview for an API so it doesn't get the banner".

Closing this though.