RFC 9239 resolves the disagreement between WHATWG and IETF w.r.t. the JavaScript MIME type. This patch removes the mention of the previously required willful violation and cleans up the MIME type list, removing any JavaScript MIME types that are now no longer mentioned in the HTML Standard.

* Modernize the definitions and usage of various fields associated with script element, e.g. by removing "scare quotes", changing names from verbose things like "the script's type" to just "type", changing flags to booleans, ensuring initial values are defined, etc. Notable field changes:
    * Rename "the script's script" to "result". This serves as preparation for other specifications, such as import maps, which will expand what that field can contain.  
    * Rename "non-blocking" to "force async" to better communicate its connection to the async="" content attribute and to avoid confusion with the blocking="" content attribute.
* Revamp "the script is ready" into three separate concepts: "delaying the load event", "mark as ready", and "steps to run when the result is ready". Fixes #5217, in particular making it so that script elements which are never marked as ready (e.g., <script type="foobar">) don't delay the load event indefinitely.
* Un-export "prepare a script". All uses of it in external specs are either monkeypatches or non-normative references.
* Rename "prepare a script" to "prepare the script element" to emphasize it's about the `<script>` element, not about the separate script concept.
* Rewrite the final of "prepare the script element" from a switch into a series of nested if/else blocks, which better communicates how we can land in the various different script element execution modes.
* Rename "execute a script block" to "execute the script element", since "block" is a strange term.
* Various other editorial improvements to those two algorithms.

Fixes #7736.

Closes #7808.

Fixes #7896.

Closes #3489.

Fixes #7893, which is a bug introduced by #7857.

See tc39/ecma262#2411.

This was introduced in f729a76 but was not implemented in browsers.

Part of #7867.

There's no need to measure the timestamp during navigation and account for beforeunload prompts. We can just use the start time already measured by Fetch.

This is in line with current WebKit implementation, and very close to Chromium implementation which currently doesn't count beforeunload time as part of the navigation time.

Closes #7716.

The original definition of "render-blocking" could be confusing because it's mostly reflecting the blocking attribute's value, and as a result, a render-blocking element may actually have never blocked rendering.

This revises the terms so that:

* "Potentially render-blocking" is used to reflect the attribute value.
* "Render-blocking" is used to indicate whether rendering is being blocked by the element.

Context: whatwg/url#692.

In particular, after this change, removing blocking="render" will no longer unblock rendering for implicitly render-blocking elements, such as parser-created stylesheet <link>s.

Closes #7856.

Closes #1792 by aligning with Gecko. The alternative model involved delaying popstate until after the load event, which is what WebKit and Blink do. But the Gecko model is simpler, more deterministic (since the load event depends on network timing), and has fewer edge cases around multiple consecutive state changes.

The only normative change here is to delay the load event of the script's preparation-time document, instead of its node document (which could change while the fetching is in progress). Closes #5160.

Otherwise, this consists of cleanups to use more precise language for certain documents, thus closing #7589, and of the pending parsing-blocking script concept to use more imperative language.

Closes w3c/preload#113.

Closes #7004 by superseding it. See also w3c/csswg-drafts#6537 and w3c/csswg-drafts#7224.

Co-authored-by: fantasai <fantasai.bugs@inkedblade.net>
Co-authored-by: Simon Pieters <zcorpan@gmail.com>
Co-authored-by: Howard Edwards <howarde.edwards@gmail.com>

A part of #1142. Although no browsers match this exactly, and implementers aren't sure this will be implementable, this is at least closer to reality than the previous spec, and reflects the direction everyone wants to go.

See #7823.

See tc39/ecma262#2670 and w3c/webappsec-csp#541 for complementary PRs.

Tests: web-platform-tests/wpt#33737.

Closes #2925.

Closes #7766.

Closes #7767.

This also includes an editorial refactoring to move more checks into the "show the picker, if applicable" algorithm, since either early-returning or throwing on certain conditions was common to all call sites.

Closes #7748.

Given that plugins are gone from the web platform (with their full removal from the spec being tracked in #6003), it is not useful. In some browsers it can be used to figure out the URL of an <object>, even when that <object> is not being used for a plugin, via params named "movie", "src", "code", or "url". But we decided to remove this behavior from browsers instead of specifying it.

This retains the HTMLParamElement interface, as well as the parser behavior of <param>.

Closes #387. Helps with #6003.

Preconnect links obtain a connection to the origin specified by their href="" attribute, taking the crossorigin="" attribute into account.

It is not yet specified for Link headers.

Closes #7760.

Fixes #7825.

We were often calling "current high resolution time" without passing in a global. This revamps the spec to pass in the global appropriately, or use the unsafe shared current time when that's necessary, or coarsen the time ourselves in cases where that's necessary.

Closes #7776. See also w3c/longtasks#98.

Closes #7598. Closes w3c/preload#114.