Fix several spec URLs

[caugner]

Summary

Fixes several spec URLs.

Accounts for:

• Features removed from the spec (implies setting deprecated: true).
• Features moved within a spec (i.e. different id).
• Features moved to another spec.
• Feature sections renamed.

Changes some spec URLs to draft, because webref/ed does not contain ids from TRs.

Test results and supporting details

Related issues

Extracted from: #23958

[github-actions]

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

[Elchi3]

Thank you!! 👍

[wbamberg]

Note that removing toJSON() from CSPViolationReportBody means it's now a dictionary, not an interface (w3c/webappsec-csp#737), so per BCD's rules, it not have BCD.

[ddbeck]

I think @wbamberg is onto something, but perhaps an even weirder thing: a window-exposed CSPViolationReportBody (plus Report and ReportBody) is now non-standard. Another interpretation here is that the deprecated state should be extended to cover the entire exposed interface that is no longer specified (and all of the spec links should be removed).

(Though I'll grant that removing the whole thing would probably be easier, at the loss of the data for the toJSON() method and the interface exposures.)

[wbamberg]

I think @wbamberg is onto something, but perhaps an even weirder thing: a window-exposed CSPViolationReportBody (plus Report and ReportBody) is now non-standard.

I think maybe the Exposed attribute doesn't apply to dictionaries: https://webidl.spec.whatwg.org/#Exposed.

There is still a "thing" called CSPViolationReportBody which merits documentation on MDN at least, but it's a dictionary now not an interface.

For BCD, AFAIK this means it doesn't exist.

For MDN, there are two options:

1. document it as a separate named entity, kind of like an interface
2. document it inline, at the point it is used, as an anonymous object, with words like "an object with the following members".

MDN's choice between (1) and (2) is pragmatic: if the docs seem better with a dictionary documented as a separate named entity (like RequestInit, say), rather than an anonymous "object with the following members", then we choose (1), otherwise we choose (2).

This change to CSPViolationReportBody stems from w3c/reporting#216, which @hamishwillee brought up in connection with COEP violation reports, which aren't going to be described in the spec as named dictionary types, but only as anonymous objects. The situation there is even weirder, because we're considering inventing a COEPViolationReportBody type, so we have a name to give this thing that we want to document. Which sounds like an awful idea, but documenting it inline as an anonymous object sounds even worse.

[ddbeck]

I think maybe the Exposed attribute doesn't apply to dictionaries: https://webidl.spec.whatwg.org/#Exposed.

I think you're right. But Exposed does apply to interfaces and did apply to CSPViolationReportBody when it was an interface (w3c/webappsec-csp#737). So now we've got two distinct things:

1. CSPViolationReportBody as an interface
2. CSPVIolationReportBody as a dictionary

The former is something that we'd track in BCD, the latter is not. But the former still exists. For example, in Chrome, window.CSPViolationReportBody is defined, which I'd expect to be true for the interface but not the dictionary.

For completeness, BCD could cover CSPViolationReportBody as an interface that is either unspecified or deprecated. For consistency with other dictionaries, BCD could remove CSPViolationReportBody entirely. But BCD can't do both because they share a name. Whether BCD treats CSPViolationReportBody as an interface or a dictionary, there's going to be either loss of true data or confusion about what it covers.

[ddbeck]

Also, I don't have a strong opinion about how MDN covers the dictionary. I don't think MDN should cover the interface. I agree that inventing COEPViolationReportBody is bad and, if that were my job, I would endeavor to do anything else (seriously, I think calling it "Anonymous COEP violation report body object" would be a mouthful but totally cromulent).

[wbamberg]

I think maybe the Exposed attribute doesn't apply to dictionaries: https://webidl.spec.whatwg.org/#Exposed.

I think you're right. But Exposed does apply to interfaces and did apply to CSPViolationReportBody when it was an interface (w3c/webappsec-csp#737). So now we've got two distinct things:

1. `CSPViolationReportBody` as an interface

2. `CSPVIolationReportBody` as a dictionary

The former is something that we'd track in BCD, the latter is not. But the former still exists. For example, in Chrome, window.CSPViolationReportBody is defined, which I'd expect to be true for the interface but not the dictionary.

For completeness, BCD could cover CSPViolationReportBody as an interface that is either unspecified or deprecated. For consistency with other dictionaries, BCD could remove CSPViolationReportBody entirely. But BCD can't do both because they share a name. Whether BCD treats CSPViolationReportBody as an interface or a dictionary, there's going to be either loss of true data or confusion about what it covers.

Ah, that's all true, indeed. Good luck.