Add speculation rules prefetch #11426

domenic · 2025-07-03T06:58:50Z

Other spec PRs that should be merged shortly after this one:

CSP integration pull request: Integrate with speculation rules w3c/webappsec-csp#776
Fetch integration pull request: Add the "speculationrules" destination fetch#1841
WICG/nav-speculation pull request to rebase on top of this: Rebase on top of HTML WICG/nav-speculation#398

This ports the relevant text from https://wicg.github.io/nav-speculation/speculation-rules.html, with minor improvements and additions. It does not port the actual navigational prefetching algorithms, which are left in https://wicg.github.io/nav-speculation/prefetch.html for now.

Part of #11123.

Notable changes from that document:

Allows treating prerender rules as prefetch rules.
Allows the presence of target_hint (a prerender-specific speculation rule key), but ignores it.
Follows the precedent set by import maps a bit more closely in how it integrates with the script processing model. Normatively, it fires error events on the script element for the few things that cause complete parsing failures. (Chromium recently changed to do this.)
Adds conformance requirements for speculation rules JSON documents, following the precedent set by import maps.
Adds explicit callouts for when the implementation may report warnings for parsing failures, following the precedent set by import maps.
Fixes a few minor bugs in the parsing algorithms. E.g., the previous text did not correctly deal with how CSS selector parsing returned a list, or called the slightly wrong algorithm for parsing URL patterns.
Simplified the processing model for the Speculation-Rules HTTP header. The previous text added various concepts around pending fetches and periodic implementation-defined processing of those fetches, all designed to allow the implementation to de-prioritize these fetches in favor of other things that happen during loading. This version instead explicitly allows an implementation-defined wait time and uses a separate task source which user agents can deprioritize.
Be explicit about when to consider speculative loads, instead of using vague language about "whenever something relevant changes".
Add re-parsing of <script type=speculationrules> on base URL changes, to match the Chromium implementation.
Slightly shorten some of the security and privacy considerations, e.g., by not mentioning mixed content concerns.

At least two implementers are interested (and none opposed):
- Chromium
- Gecko
- WebKit is in support of a subset of the functionality here
Tests are written and can be reviewed and commented upon at:
- https://wpt.fyi/results/speculation-rules (includes updates to error behavior mentioned above)
Implementation bugs are filed:
- Chromium: N/A
- Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1969396
- WebKit: https://bugs.webkit.org/show_bug.cgi?id=295193
- Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): N/A
- Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): N/A
Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A
MDN issue is filed: N/A, MDN already documents this well
The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

/acknowledgements.html ( diff )
/browsers.html ( diff )
/browsing-the-web.html ( diff )
/document-lifecycle.html ( diff )
/document-sequences.html ( diff )
/iana.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/interaction.html ( diff )
/links.html ( diff )
/nav-history-apis.html ( diff )
/references.html ( diff )
/scripting.html ( diff )
/semantics.html ( diff )
/urls-and-fetching.html ( diff )
/webappapis.html ( diff )
/speculative-loading.html ( diff )

domenic · 2025-07-09T06:58:22Z

The spec text here is done and ready for review!

Marking "do not merge yet" until I get the other prerequisites listed in the OP done (mostly PRs against other specs).

Part of whatwg/html#11426, for requests initiated by the `Speculation-Rules` HTTP header.

whatwg/html#11426 upstreams most of the speculation rules specification to HTML. Remove the upstreamed portions, and add references to the PR and PR preview.

domenic · 2025-07-18T04:12:23Z

This is now fully ready for review, including all prerequisites. I'll keep "do not merge yet" to reflect that we need to get #11442 reviewed and merged first, but that's a pretty small change...

This CL introduces error handling for <script type=speculationrules>, mirroring the behavior of <script type=importmap>. Specifically, it adds error events for two cases: - Inline speculation rules with unparsable JSON. - External speculation rules, which are not yet supported. This is verified by new web platform tests. This follows the spec change at whatwg/html#11426. Change-Id: I9b0776b86059f6c8734d57c17f50ed26e89215da Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6758353 Reviewed-by: Hiroki Nakagawa <[email protected]> Commit-Queue: Domenic Denicola <[email protected]> Cr-Commit-Position: refs/heads/main@{#1488632}

This CL introduces error handling for <script type=speculationrules> with invalid ruleset-level tags. This changes the behavior: previously we would ignore such tags and preload with the null tag. But now, we error the entire <script type=speculationrules>, since it is better to avoid preloading if the web developer is expecting it to get a certain tag and we cannot fulfill that request. This matches the spec update at whatwg/html#11426. Bug: None Change-Id: I5d2211510bd4e3a3ecce15010325b411f18fde3a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6746174 Commit-Queue: Domenic Denicola <[email protected]> Reviewed-by: Danil Somsikov <[email protected]> Reviewed-by: Hiroki Nakagawa <[email protected]> Cr-Commit-Position: refs/heads/main@{#1488633}

This CL introduces error handling for <script type=speculationrules>, mirroring the behavior of <script type=importmap>. Specifically, it adds error events for two cases: - Inline speculation rules with unparsable JSON. - External speculation rules, which are not yet supported. This is verified by new web platform tests. This follows the spec change at whatwg/html#11426. Change-Id: I9b0776b86059f6c8734d57c17f50ed26e89215da Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6758353 Reviewed-by: Hiroki Nakagawa <[email protected]> Commit-Queue: Domenic Denicola <[email protected]> Cr-Commit-Position: refs/heads/main@{#1488632}

This CL introduces error handling for <script type=speculationrules> with invalid ruleset-level tags. This changes the behavior: previously we would ignore such tags and preload with the null tag. But now, we error the entire <script type=speculationrules>, since it is better to avoid preloading if the web developer is expecting it to get a certain tag and we cannot fulfill that request. This matches the spec update at whatwg/html#11426. Bug: None Change-Id: I5d2211510bd4e3a3ecce15010325b411f18fde3a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6746174 Commit-Queue: Domenic Denicola <[email protected]> Reviewed-by: Danil Somsikov <[email protected]> Reviewed-by: Hiroki Nakagawa <[email protected]> Cr-Commit-Position: refs/heads/main@{#1488633}

This CL introduces error handling for <script type=speculationrules>, mirroring the behavior of <script type=importmap>. Specifically, it adds error events for two cases: - Inline speculation rules with unparsable JSON. - External speculation rules, which are not yet supported. This is verified by new web platform tests. This follows the spec change at whatwg/html#11426. Change-Id: I9b0776b86059f6c8734d57c17f50ed26e89215da Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6758353 Reviewed-by: Hiroki Nakagawa <[email protected]> Commit-Queue: Domenic Denicola <[email protected]> Cr-Commit-Position: refs/heads/main@{#1488632}

This CL introduces error handling for <script type=speculationrules> with invalid ruleset-level tags. This changes the behavior: previously we would ignore such tags and preload with the null tag. But now, we error the entire <script type=speculationrules>, since it is better to avoid preloading if the web developer is expecting it to get a certain tag and we cannot fulfill that request. This matches the spec update at whatwg/html#11426. Bug: None Change-Id: I5d2211510bd4e3a3ecce15010325b411f18fde3a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6746174 Commit-Queue: Domenic Denicola <[email protected]> Reviewed-by: Danil Somsikov <[email protected]> Reviewed-by: Hiroki Nakagawa <[email protected]> Cr-Commit-Position: refs/heads/main@{#1488633} Co-authored-by: Domenic Denicola <[email protected]>

This CL introduces error handling for <script type=speculationrules>, mirroring the behavior of <script type=importmap>. Specifically, it adds error events for two cases: - Inline speculation rules with unparsable JSON. - External speculation rules, which are not yet supported. This is verified by new web platform tests. This follows the spec change at whatwg/html#11426. Change-Id: I9b0776b86059f6c8734d57c17f50ed26e89215da Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6758353 Reviewed-by: Hiroki Nakagawa <[email protected]> Commit-Queue: Domenic Denicola <[email protected]> Cr-Commit-Position: refs/heads/main@{#1488632}

…sts#53822) This CL introduces error handling for <script type=speculationrules> with invalid ruleset-level tags. This changes the behavior: previously we would ignore such tags and preload with the null tag. But now, we error the entire <script type=speculationrules>, since it is better to avoid preloading if the web developer is expecting it to get a certain tag and we cannot fulfill that request. This matches the spec update at whatwg/html#11426. Bug: None Change-Id: I5d2211510bd4e3a3ecce15010325b411f18fde3a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6746174 Commit-Queue: Domenic Denicola <[email protected]> Reviewed-by: Danil Somsikov <[email protected]> Reviewed-by: Hiroki Nakagawa <[email protected]> Cr-Commit-Position: refs/heads/main@{#1488633} Co-authored-by: Domenic Denicola <[email protected]>

…sts#53822) This CL introduces error handling for <script type=speculationrules> with invalid ruleset-level tags. This changes the behavior: previously we would ignore such tags and preload with the null tag. But now, we error the entire <script type=speculationrules>, since it is better to avoid preloading if the web developer is expecting it to get a certain tag and we cannot fulfill that request. This matches the spec update at whatwg/html#11426. Bug: None Change-Id: I5d2211510bd4e3a3ecce15010325b411f18fde3a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6746174 Commit-Queue: Domenic Denicola <[email protected]> Reviewed-by: Danil Somsikov <[email protected]> Reviewed-by: Hiroki Nakagawa <[email protected]> Cr-Commit-Position: refs/heads/main@{#1488633}

This CL introduces error handling for <script type=speculationrules> with invalid ruleset-level tags. This changes the behavior: previously we would ignore such tags and preload with the null tag. But now, we error the entire <script type=speculationrules>, since it is better to avoid preloading if the web developer is expecting it to get a certain tag and we cannot fulfill that request. This matches the spec update at whatwg/html#11426. Bug: None Change-Id: I5d2211510bd4e3a3ecce15010325b411f18fde3a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6746174 Commit-Queue: Domenic Denicola <[email protected]> Reviewed-by: Danil Somsikov <[email protected]> Reviewed-by: Hiroki Nakagawa <[email protected]> Cr-Commit-Position: refs/heads/main@{#1488633}

This ports the relevant text from https://wicg.github.io/nav-speculation/speculation-rules.html, with minor improvements and additions. It does *not* port the actual navigational prefetching algorithms, which are left in https://wicg.github.io/nav-speculation/prefetch.html for now. Notable changes from that document: * Allows treating prerender rules as prefetch rules. * Allows the presence of target_hint (a prerender-specific speculation rule key), but ignores it. * Follows the precedent set by import maps a bit more closely in how it integrates with the script processing model. Normatively, it fires error events on the script element for the few things that cause complete parsing failures. * Adds conformance requirements for speculation rules JSON documents, following the precedent set by import maps. * Adds explicit callouts for when the implementation may report warnings for parsing failures, following the precedent set by import maps. * Fixes a few minor bugs in the parsing algorithms. E.g., the previous text did not correctly deal with how CSS selector parsing returned a list, or called the slightly wrong algorithm for parsing URL patterns. * Simplified the processing model for the Speculation-Rules HTTP header. The previous text added various concepts around pending fetches and periodic implementation-defined processing of those fetches, all designed to allow the implementation to de-prioritize these fetches in favor of other things that happen during loading. This version instead explicitly allows an implementation-defined wait time and uses a separate task source which user agents can deprioritize. * Be explicit about when to consider speculative loads, instead of using vague language about "whenever something relevant changes". * Add re-parsing of <script type=speculationrules> on base URL changes, to match the Chromium implementation. * Slightly shorten some of the security and privacy considerations, e.g., by not mentioning mixed content concerns.

whatwg/html#11426 upstreams most of the speculation rules specification to HTML. Remove the upstreamed portions, and add references to the PR and PR preview.

…n rules tags, a=testonly Automatic update from web-platform-tests Fire error events for invalid speculation rules tags (#53822) This CL introduces error handling for <script type=speculationrules> with invalid ruleset-level tags. This changes the behavior: previously we would ignore such tags and preload with the null tag. But now, we error the entire <script type=speculationrules>, since it is better to avoid preloading if the web developer is expecting it to get a certain tag and we cannot fulfill that request. This matches the spec update at whatwg/html#11426. Bug: None Change-Id: I5d2211510bd4e3a3ecce15010325b411f18fde3a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6746174 Commit-Queue: Domenic Denicola <[email protected]> Reviewed-by: Danil Somsikov <[email protected]> Reviewed-by: Hiroki Nakagawa <[email protected]> Cr-Commit-Position: refs/heads/main@{#1488633} Co-authored-by: Domenic Denicola <[email protected]> -- wpt-commits: 8c89451fb0955254073a736d55dc077abff0e391 wpt-pr: 53822

hsivonen · 2025-07-25T07:42:32Z

Could you, please, add a Note remarking the rationale for non-support for the Speculation-Rules HTTP header via meta http-equiv? (To be clear, this is not a request for a normative change.)

annevk · 2025-07-25T08:02:13Z

We generally don't support new headers through http-equiv because we don't want mutable policies. That seems worth documenting, but it doesn't seem specific to this feature.

domenic · 2025-07-28T06:05:35Z

I've added #11494 to document that in the overall definition of http-equiv.

…r invalid speculation rules, a=testonly Automatic update from web-platform-tests Fire error events for invalid speculation rules This CL introduces error handling for <script type=speculationrules>, mirroring the behavior of <script type=importmap>. Specifically, it adds error events for two cases: - Inline speculation rules with unparsable JSON. - External speculation rules, which are not yet supported. This is verified by new web platform tests. This follows the spec change at whatwg/html#11426. Change-Id: I9b0776b86059f6c8734d57c17f50ed26e89215da Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6758353 Reviewed-by: Hiroki Nakagawa <[email protected]> Commit-Queue: Domenic Denicola <[email protected]> Cr-Commit-Position: refs/heads/main@{#1488632} -- wpt-commits: 1d91c36a40b59a975a869f4d5749ff3004839dab wpt-pr: 53821

…eculation rules tags", a=testonly Automatic update from web-platform-tests Fire error events for invalid speculation rules tags (#53822) This CL introduces error handling for <script type=speculationrules> with invalid ruleset-level tags. This changes the behavior: previously we would ignore such tags and preload with the null tag. But now, we error the entire <script type=speculationrules>, since it is better to avoid preloading if the web developer is expecting it to get a certain tag and we cannot fulfill that request. This matches the spec update at whatwg/html#11426. Bug: None Change-Id: I5d2211510bd4e3a3ecce15010325b411f18fde3a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6746174 Commit-Queue: Domenic Denicola <[email protected]> Reviewed-by: Danil Somsikov <[email protected]> Reviewed-by: Hiroki Nakagawa <[email protected]> Cr-Commit-Position: refs/heads/main@{#1488633} -- wpt-commits: 978340f5361ac897deb74a619980fea749313f28 wpt-pr: 53905

hsivonen · 2025-07-28T08:33:28Z

I've added #11494 to document that in the overall definition of http-equiv.

That works. Thanks.

…n rules tags, a=testonly Automatic update from web-platform-tests Fire error events for invalid speculation rules tags (#53822) This CL introduces error handling for <script type=speculationrules> with invalid ruleset-level tags. This changes the behavior: previously we would ignore such tags and preload with the null tag. But now, we error the entire <script type=speculationrules>, since it is better to avoid preloading if the web developer is expecting it to get a certain tag and we cannot fulfill that request. This matches the spec update at whatwg/html#11426. Bug: None Change-Id: I5d2211510bd4e3a3ecce15010325b411f18fde3a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6746174 Commit-Queue: Domenic Denicola <[email protected]> Reviewed-by: Danil Somsikov <[email protected]> Reviewed-by: Hiroki Nakagawa <[email protected]> Cr-Commit-Position: refs/heads/main@{#1488633} Co-authored-by: Domenic Denicola <[email protected]> -- wpt-commits: 8c89451fb0955254073a736d55dc077abff0e391 wpt-pr: 53822

…r invalid speculation rules, a=testonly Automatic update from web-platform-tests Fire error events for invalid speculation rules This CL introduces error handling for <script type=speculationrules>, mirroring the behavior of <script type=importmap>. Specifically, it adds error events for two cases: - Inline speculation rules with unparsable JSON. - External speculation rules, which are not yet supported. This is verified by new web platform tests. This follows the spec change at whatwg/html#11426. Change-Id: I9b0776b86059f6c8734d57c17f50ed26e89215da Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6758353 Reviewed-by: Hiroki Nakagawa <[email protected]> Commit-Queue: Domenic Denicola <[email protected]> Cr-Commit-Position: refs/heads/main@{#1488632} -- wpt-commits: 1d91c36a40b59a975a869f4d5749ff3004839dab wpt-pr: 53821

…eculation rules tags", a=testonly Automatic update from web-platform-tests Fire error events for invalid speculation rules tags (#53822) This CL introduces error handling for <script type=speculationrules> with invalid ruleset-level tags. This changes the behavior: previously we would ignore such tags and preload with the null tag. But now, we error the entire <script type=speculationrules>, since it is better to avoid preloading if the web developer is expecting it to get a certain tag and we cannot fulfill that request. This matches the spec update at whatwg/html#11426. Bug: None Change-Id: I5d2211510bd4e3a3ecce15010325b411f18fde3a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6746174 Commit-Queue: Domenic Denicola <[email protected]> Reviewed-by: Danil Somsikov <[email protected]> Reviewed-by: Hiroki Nakagawa <[email protected]> Cr-Commit-Position: refs/heads/main@{#1488633} -- wpt-commits: 978340f5361ac897deb74a619980fea749313f28 wpt-pr: 53905

domfarolino

First pass, although I'm certainly less than half-way through. Mostly small things and questions so far.

source

domfarolino · 2025-07-29T19:37:43Z

source

+
+     <li><p>If <var>prefetchRecord</var> is not <span>still being speculated</span> given
+     <var>prefetchCandidates</var>, then <span data-x="prefetch-record-cancel-and-discard">cancel
+     and discard</span> <var>prefetchRecord</var> given <var>document</var>.</p></li>


Can this result in any prefetch request being canceled other than the one associated with the triggering of this algorithm to run in the first place? I'm asking because I know spec-wise we simplify things by "considering all speculative loads" in a state-less way whenever any individual link-specific thing happened, causing this algorithm to run. And I'm just trying to make sure it's not possible for a <a>'s href attribute to be mutated, and for this algorithm to run and cancel an unrelated speculative load (because we evaluate all the thingz), in a way that a smarter implementation would never do.

In spirit: no. But literally: yes.

This is because of the microtask queuing behavior. If you do

mutateLink1(); mutateLink2(); mutateLink3();

then mutateLink1() queues a microtask to "consider speculative loads", mutateLink2() and mutateLink3() do nothing, and by the time the microtask runs, "consider speculative loads" will cancel prefetches from all 3 links.

In the Chromium implementation, what this looks like is all the various steps that call "consider speculative loads" add to a list of dirty candidates, and so this step looks at the dirty list.

Do you think explaining this implementation strategy would be worth a note?

OK so it is possible for this to cancel multiple things beyond what the thing invoking this algorithm would do, but not so much "in a way that a smarter implementation would never do" since implementations achieve the same outcome just with a different, more stateful mechanism, if I'm correct. So the observable results shouldn't differ. I think that's worth a pretty brief note, yeah!

source

domfarolino · 2025-08-06T02:52:25Z

source

+  elements, given <var>insertedNode</var>, are:</p>
+
+  <ol>
+   <li><p><span>Consider speculative loads</span> given <var>insertedNode</var>'s <span>node


Insertion steps do not imply connectedness, so just like the Chromium implementation, you'll need a connected check here, or you can use the post-connection steps (but you'd want to adjust the implementation to match that, since it's observable). Your best bet is just to add a connected check here and elsewhere relevant.

domfarolino · 2025-08-06T02:53:39Z

source

+  <p>The <span>HTML element removing steps</span> for <code>a</code> and <code>area</code> elements,
+  given <var>removedNode</var> and <var>oldParent</var>, are:</p>
+
+  <ol>


Similarly, you'll want to only proceed if <var>oldParent</var> was connected. This matches Chromium too.

domfarolino · 2025-08-06T02:56:27Z

source

+
+   <li>
+    <p>If <var>localName</var> is <code data-x="attr-hyperlink-href">href</code>, then <span
+    data-x="concept-hyperlink-url-set">set the url</span> given <var>element</var>.</p>


We should really find a way to lean on the weird, unlinkable, unreferenced "change" definition in https://html.spec.whatwg.org/C#dom-trees someday.... but not today.

domfarolino · 2025-08-06T02:57:21Z

source

+    <span data-x="url parser">parsing</span> them involves a <span>Blob URL Store</span> lookup.</p>
+   </li>
+
+   <!-- PRERENDERING: also monitor target="" for target-hint. -->


I'm confused why this is here? It's just a breadcrumb for when we eventually upstream prerendering? Are we likely to forget to do this, or inversely, are we like to remember to scan through all PRERENDERING: instances to ensure we completed the full upstreaming?

zcorpan · 2025-08-07T13:56:22Z

source

+   types</a> includes the <code data-x="rel-noreferrer">noreferrer</code> keyword, then return
+   "<code data-x="">no-referrer</code>".</p></li>
+
+   <li><p>Return the current state of <var>subject</var>'s <code data-x="">referrerpolicy</code>


This was not linked previously, but it seems like it should be linked.

Suggested change

<li><p>Return the current state of <var>subject</var>'s <code data-x="">referrerpolicy</code>

<li><p>Return the current state of <var>subject</var>'s <code data-x="attr-hyperlink-referrerpolicy">referrerpolicy</code>

zcorpan · 2025-08-07T14:23:03Z

source

+    <p>The user agent may <span data-x="list append">append</span> "<code
+    data-x="">prerender</code>" to <var>typesToTreatAsPrefetch</var>.</p>


I think this means that "requires": ["anonymous-client-ip-when-cross-origin"] in prerender will be honored, but would be ignored when prerender is supported as prerender. Is that intended?

zcorpan · 2025-08-07T14:36:40Z

source

+      </ol>
+     </li>
+
+     <li><p>Return a <span>document rule CSS selector predicate</span> whose <span


In spec land it's just selector, not CSS selector.

zcorpan · 2025-08-07T14:37:21Z

source

+
+      <p class="note">Such links, though present in <var>document</var>, aren't available for the
+      user to interact with, and thus are unlikely to be good candidates. In addition, they might
+      not have their style or layout computed, which might make CSS selector matching less efficient


Suggested change

not have their style or layout computed, which might make CSS selector matching less efficient

not have their style or layout computed, which might make selector matching less efficient

zcorpan · 2025-08-07T14:57:09Z

source

+    data-x="">params=("a")</code>.</p></li>
+   </ol>
+
+   <p>With the current definition fo <span data-x="sl-candidate-redundant-with">redundant


Typo

Suggested change

<p>With the current definition fo <span data-x="sl-candidate-redundant-with">redundant

<p>With the current definition of <span data-x="sl-candidate-redundant-with">redundant

zcorpan · 2025-08-07T16:15:04Z

source

+  </ol>
+
+  <p>To <dfn>compute a speculative load referrer policy</dfn> given a <span>speculation rule</span>
+  <var>rule</var> and an <code>HTMLHyperlinkElementUtils</code>-or-null <var>link</var>:</p>


I found it a bit surprising to reference HTMLHyperlinkElementUtils here since it's a mixin, but maybe it's OK. Alternative could be "a or area element"

domfarolino · 2025-08-07T14:57:05Z

source

+
+    <ol>
+     <li><p><span>Unregister speculation rules</span> given <var>removedNode</var>'s <span>relevant
+     global object</span> and <var>removedNode</var>'s <span


Removing does not imply connected (see <var>isParentConnected</var> in https://dom.spec.whatwg.org/#concept-node-remove), so it is possible that <var>script</var> is in a detached document, and that its relevant global object is... null, right? Actually I'm curious how the implementation handles this, but I couldn't find any RemovedFrom() override in Chromium's HTMLScriptElement.

domfarolino · 2025-08-07T15:37:29Z

source

+
+  <ol>
+   <li><p>Run the <code>script</code> <span>HTML element post-connection steps</span>, given
+   <var>changedNode</var>.</p></li>


(Not actionable / just FYI, after reviewing this I decided to make #11543, and make this algorithm implement the connectedness pre-condition, after confusing myself about connectedness requirements.)

domenic added addition/proposal New features or enhancements topic: navigation labels Jul 3, 2025

domenic marked this pull request as draft July 3, 2025 06:59

domenic mentioned this pull request Jul 9, 2025

Patch HTML's base URL stuff to be in terms of DOM whatwg/dom#61

Closed

domenic force-pushed the speculation-rules branch from 7ff9848 to c23dcae Compare July 9, 2025 06:51

domenic marked this pull request as ready for review July 9, 2025 06:54

domenic added the do not merge yet Pull request must not be merged per rationale in comment label Jul 9, 2025

domenic force-pushed the speculation-rules branch from c23dcae to 6ea2451 Compare July 9, 2025 06:58

domenic added a commit to whatwg/fetch that referenced this pull request Jul 10, 2025

Add the "speculationrules" destination

c649784

Part of whatwg/html#11426, for requests initiated by the `Speculation-Rules` HTTP header.

This was referenced Jul 10, 2025

Add the "speculationrules" destination whatwg/fetch#1841

Open

"speculationrules" request destination missing mdn/content#40289

Closed

Integrate with speculation rules w3c/webappsec-csp#776

Open

domenic force-pushed the speculation-rules branch 4 times, most recently from 33f0b13 to 647afa5 Compare July 11, 2025 02:42

domenic added a commit to WICG/nav-speculation that referenced this pull request Jul 11, 2025

Rebase on top of HTML

0ce01bb

whatwg/html#11426 upstreams most of the speculation rules specification to HTML. Remove the upstreamed portions, and add references to the PR and PR preview.

domenic mentioned this pull request Jul 11, 2025

Rebase on top of HTML WICG/nav-speculation#398

Merged

chromium-wpt-export-bot mentioned this pull request Jul 18, 2025

[speculation-rules] Fire error events for invalid speculation rules web-platform-tests/wpt#53821

Merged

chromium-wpt-export-bot mentioned this pull request Jul 18, 2025

Fire error events for invalid speculation rules tags web-platform-tests/wpt#53822

Merged

jonathan-j-lee mentioned this pull request Jul 22, 2025

Reland "Fire error events for invalid speculation rules tags" web-platform-tests/wpt#53905

Merged

domenic force-pushed the speculation-rules branch from 647afa5 to d56b452 Compare July 23, 2025 02:10

domenic removed the do not merge yet Pull request must not be merged per rationale in comment label Jul 23, 2025

domenic added a commit to WICG/nav-speculation that referenced this pull request Jul 23, 2025

Rebase on top of HTML

b75b9f7

whatwg/html#11426 upstreams most of the speculation rules specification to HTML. Remove the upstreamed portions, and add references to the PR and PR preview.

domenic requested a review from domfarolino July 24, 2025 05:38

domfarolino reviewed Jul 29, 2025

View reviewed changes

domenic added 5 commits July 30, 2025 16:08

Fix easy things

625da24

Undo some unrelated wrapping changes

47d263f

Merge remote-tracking branch 'origin/main' into speculation-rules

95d5524

Add a very important call site for "consider speculative loads"

b7b8f07

Create groups and enact the primary one in each

28571ea

domfarolino reviewed Aug 6, 2025

View reviewed changes

zcorpan reviewed Aug 7, 2025

View reviewed changes

domfarolino reviewed Aug 7, 2025

View reviewed changes

	<li><p>Return the current state of <var>subject</var>'s <code data-x="">referrerpolicy</code>
	<li><p>Return the current state of <var>subject</var>'s <code data-x="attr-hyperlink-referrerpolicy">referrerpolicy</code>

		<p>The user agent may <span data-x="list append">append</span> "<code
		data-x="">prerender</code>" to <var>typesToTreatAsPrefetch</var>.</p>

	not have their style or layout computed, which might make CSS selector matching less efficient
	not have their style or layout computed, which might make selector matching less efficient

	<p>With the current definition fo <span data-x="sl-candidate-redundant-with">redundant
	<p>With the current definition of <span data-x="sl-candidate-redundant-with">redundant

Add speculation rules prefetch #11426

Are you sure you want to change the base?

Add speculation rules prefetch #11426

Uh oh!

Conversation

domenic commented Jul 3, 2025 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

domenic commented Jul 9, 2025

Uh oh!

domenic commented Jul 18, 2025

Uh oh!

hsivonen commented Jul 25, 2025

Uh oh!

annevk commented Jul 25, 2025

Uh oh!

domenic commented Jul 28, 2025

Uh oh!

hsivonen commented Jul 28, 2025

Uh oh!

domfarolino left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

domenic commented Jul 3, 2025 •

edited by pr-preview bot

Loading