WordPress.org
Get WordPress

Make WordPress Core

Opened 4 hours ago

Last modified 17 minutes ago

#66156 new defect (bug)

W3C Error : Element style not allowed as child of element body in this context.

Reported by: gaet Owned by:
Priority: normal Milestone: Awaiting Review
Component: General Version:
Severity: normal Keywords:
Cc: Focuses:

Description

Hi,
Whenever I run a W3C check on WordPress sites, this error always pops up. How can I avoid it?

Element style not allowed as child of element body in this context.
<style id="core-block-supports-inline-css">

Attachments (1)

Capture d’écran 2026-09-22 à 10.30.17.png​ (117.4 KB ) - added by gaet 4 hours ago.

Download all attachments as: .zip

Change History (3)

@gaet
4 hours ago

#1 @iamchitti
58 minutes ago

Thanks for the report. This is coming from ​wp_enqueue_stored_styles(). For classic themes, block-support CSS (and duotone SVG filters) is intentionally printed at ​wp_footer (priority 1) rather than wp_head, to avoid adding render-blocking inline CSS for styles that may only be known once the page content has rendered. The same applies to duotone's ​SVG filter output, also hooked to wp_footer. The -inline-css suffix on the tag's id (<style id="core-block-supports-inline-css">) is just how ​WP_Styles prints any inline style - it's {handle}-inline-css for every inline style tag, nothing specific to this handle.

Per the ​WHATWG HTML spec, <style> is only permitted where metadata content is expected (i.e. <head>, or inside a <noscript> that's a child of <head>) - it's no longer valid as flow content in <body> (the old scoped attribute exemption was removed years ago). Browsers are lenient and render it fine, but W3C's validator correctly flags it per spec.

This looks like an intentional tradeoff rather than an oversight. Moving this back into <head> for classic themes would reintroduce the render-blocking/ordering issue it was moved away from.

#2 @gaet
17 minutes ago

Hello,
Thank you for these explanations; I fully understand why this code is included in the wp_footer.
However, even though browsers understand how this code works and execute it correctly, the W3C still generates this error, meaning it isn’t valid code according to web standards… Should we contact the W3C? Is there a way within WordPress to do things differently or to ignore this error?

Thanks

Note: See TracTickets for help on using tickets.