Error in validator.w3 (After updating to version 6.8)

[mike77777]

After updating the site to version 6.8, in the validator – validator.w3.org, an error appeared – ‘ Error: Bad value speculationrules for attribute type on element script: Subtype missing.From line 778, column 1; to line 778, column 32v>↩</div>↩<script type="speculationrules">↩{"pre’

How can I fix it? I have no errors on my site except this one and it’s very frustrating.

During the previous update I also had an error in the validator related to – contain-intrinsic-size, I had to solve it myself by adding to the file – functions.php, the line add_filter('wp_img_tag_add_auto_sizes', '__return_false'); more about this – https://core.trac.wordpress.org/ticket/62413.

[sabernhardt]

(​original report on forums)

[robin_dean]

I'm faced with the same bug. This is invalid HTML, as was the "contain-intrinsic-size" issue. Please, stop adding invalid html to the core or even better, check that the end result is valid html (in my case html5).

[peterwilsoncc]

As documented on MDN, speculationrules is a ​valid value for the type attribute for the Speculation Rules API. You can read more about WordPress's use of ​speculative loading in the dev-note.

While the W3C's validator is a helpful tool, it can be a little behind browser implementations as features gain support during the late stages of the standardization process. WordPress focuses on what will be useful for users and will often implement such features as they arrive in browsers. This is one such case.

If you wish to remove the speculative loading API from your site, you can use the wp_speculation_rules_configuration hook to do so.

add_filter( 'wp_speculation_rules_configuration', '__return_null' );

I'm going to close this ticket off as wontfix, as I expect the validator will recognise the speculation rules API in a future update.

[robin_dean]

Then, maybe default to disabled. Let us decide.

Now I get to edit each of my client's functions.php, one at a time, insert this solution.

[samiamnot]

@robin_dean, just out of curiosity, why would you bother changing things to score better on a validator that is out of date? Had the speculation rules bothered you on its own (it was added to improve performance), I would understand you making changes to slow things down (you may worry about the possible server hit from preloading), but why do it just for a validation that is simply out of date? This is sheer curiosity, and not a knock of any sort.

[robin_dean]

I'm not going to answer your question as it doesn't interest me.

Tell me what validator I'm using. I'm not here because the thread starter mentions validator.w3. I'm here because it's invalid html.

So please, by all means, tell me which validator you believe to be the current standard, the one which doesn't throw a validation error regarding the topic at hand.

[sabernhardt]

The W3C validator is probably the best, but it's not perfect.

I highly recommend reporting the speculationrules error to them so they know to update it:
​https://validator.w3.org/contribute.html

[karl53]

"As documented on MDN, speculationrules is a valid value for the type attribute for the Speculation Rules API."

The error I get isn't that the 'speculationrules' itself isn't valid. This is what I get:

"Bad value “speculationrules” for attribute “type” on element “script”: Subtype missing."

So the problem is a missing subtype.

I just wanted to share this with you. The W3.org local Java-based tool can't parse the URL on Windows, but it can on Mac.

Replying to peterwilsoncc:

As documented on MDN, speculationrules is a ​valid value for the type attribute for the Speculation Rules API. You can read more about WordPress's use of ​speculative loading in the dev-note.

While the W3C's validator is a helpful tool, it can be a little behind browser implementations as features gain support during the late stages of the standardization process. WordPress focuses on what will be useful for users and will often implement such features as they arrive in browsers. This is one such case.

If you wish to remove the speculative loading API from your site, you can use the wp_speculation_rules_configuration hook to do so.

add_filter( 'wp_speculation_rules_configuration', '__return_null' );

I'm going to close this ticket off as wontfix, as I expect the validator will recognise the speculation rules API in a future update.

[sabernhardt]

#63965 was marked as a duplicate.

[dmsnell]

I realize that I’m late to the party and this is closed, but I spend a lot of time pouring over the HTML spec, implementing HTML parsers, and building pieces of browser engines. I wanted to share more context since there’s a lot in this thread being tossed around that doesn’t match my understanding of how the web and the cooperation between browser vendors, the WhatWG, and the W3C works.

---

MDN also has a tendency to lag the specs. If anyone is interested in the relevant section:

The script element has two core attributes. The type attribute allows customization of the type of script represented:
...

• Setting the attribute to an ASCII case-insensitive match for "speculationrules" means that the script defines a speculation rule set, containing JSON that will be used to describe speculative loads.

​https://html.spec.whatwg.org/#attr-script-type

The W3 validator appears to have been updated between the time of reporting this and now as the reported input passes validation. WordPress was producing valid HTML at the time of the report, but HTML is a living standard and changes frequently. It just so happened to be ahead of the validator.

"Bad value “speculationrules” for attribute “type” on element “script”: Subtype missing."

It seems likely that the validator in use was attempting to MIME-decode the type, which is what a browser should do if the type is not a valid JavaScript MIME type essence match (what a mouthful!) or module, importmap, or speculationrules. That implies it was outdated and thought it should parse in the last category: non-JavaScript MIME types.

<script type=speculationrules> was added in ​commit c6314c8a of the HTML spec on September 10, 2025. Like most changes to the HTML spec, they occur after at least two browsers/“implementors” have ​implemented the features. In this case, Chrome had already been supporting the speculationrules since around March, 2025.

It can be very confusing to follow the lifecycle of HTML spec changes, particularly because the spec follows actual adoption. In a case like this, every browser must treat the contents of the SCRIPT of unknown type as opaque text and not execute it. I can sympathize with the desire to pass validation; those flags and warnings really eat away at you! But in some cases it’s just a false flag.

[sabernhardt]

The W3 validator appears to have been updated between the time of reporting this and now as the reported input passes validation.

According to the GitHub issue, the validator rules were fixed last month.
​https://github.com/validator/validator/issues/1814