HTML Validation Error: Element style not allowed as child of element body in this context

[oldrup]

Description

Hey peeps

After upgrading to WordPress 5.9, my sites no longer HTML validate, but throws the validation error "Error: Element style not allowed as child of element body in this context"

For a more detailed error report, please see: https://validator.w3.org/nu/?showsource=yes&doc=https%3A%2F%2Fdev.oldrup.dk%2Fwp59%2Fsample-page%2F

These errors seem to be styling of blocks, given a dynamic .wp-container class, those being injected within the body tag:

These errors appear regardless of choice of theme.

Under WordPress 5.8 the sites validated flawlessly.

Could it be possible to store the styling in a CSS file instead, or somewhere else in the document, not provoking this error?

Please let me know if I can do anything to help troubleshooting this one.

Bjarne

Step-by-step reproduction instructions

To reproduce, create a new WP 5.9 installation, and validate the built-in sample page.

Test site available at: https://dev.oldrup.dk/wp59/sample-page/

Screenshots, screen recording, code snippet

No response

Environment info

WordPress 5.9. Any theme. No plugins.

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[Klemart3D]

Official wordpress.org (on v.6.0-alpha) also displaying this error:
https://validator.w3.org/nu/?doc=https%3A%2F%2Fwordpress.org%2F

Maybe related with following issues:
https://core.trac.wordpress.org/ticket/53494
https://core.trac.wordpress.org/ticket/55148

[paaljoachim]

I believe these are associated in some way.

HTML in Post Title causes error in the block editor.
#39395

HTML tags in post titles are gone when editing existing posts
#38668

Home.html displays title from query loop instead of post-title
#39187

[cheestudio]

Hi all,

What is the status of this issue? This is causing all our sites to suddenly fail validation and is causing alarm amongst clients, especially ones where HTML validation is required to pass accessibility audits.

[oldrup]

@cheestudio To be blunt, you should not expect this issue to be solved. WordPress and Gutenberg are headed in a direction with even more inline styling. There is a "style engine" idea/project in the works, which might address restoring HTML validation, but it is a huge undertaking, and to be honest, I'm not sure if it will be given much priority with all the clearly visible FSE related tasks also at hand.

So what can you do?

1. You can probably get rid of the inline styling, by disabling Gutenberg and its styles all together, and use a page builder, which offers to store styling in a style sheet, like Elementor. There are filters and plugins for that - let me know if you need a hint.

2. If you, like me, have created content with Gutenberg for years, disabling Gutenberg is clearly not an option. But, you can use a common caching plugin option, to "pull out" the CSS styling from HTML and place et in a style sheet instead, where it, in my opinion, belongs. I'm using LiteSpeed caching, and the option there, looks like this:

That fixes the HTML output, which now validates, and won't alarm clients. I totally get you - my clients are also upset about this, and it affects their trust on WordPress and us as creators.

I hope that workaround may help you. It's the only "solution" I've found since I updated to WP 5.9 in February. 😐

[cheestudio]

@oldrup Thank you for this detailed reply. I understand from a performance perspective why inline styling has become popular (again), but this is unfortunate to see that they are doing so at the expense of current, and long established, web standards.

I'm familiar with plugins and solutions out there that will resolve this issue through a roundabout way, but I was hoping for something more fundamental and native....but it sounds like that's not a possibility anytime soon. 😕

[skorasaurus]

For what it's worth, this is W3C's stance on it - using style element within the body element - whatwg/html#1605

[AslanGM]

We need update, guys.
Will you remove this issue or should I recreate the core blocks?

[Zestastic]

Has anyone had any luck fixing this issue? It's rampant on a page I'm working on. I'm getting 586 errors throughout the entire 86 page website. If it's caused by Gutenberg Blocks, should I remove them and find another way to recreate my footer?

[oldrup]

Pentium errors, huh 😁

If it's caused by Gutenberg Blocks, should I remove them and find another way to recreate my footer?

If you are using a classic (non FSE) theme, you can install the Classic Widgets plugin and recreate your footer using the classic widgets. These are typically passing the HTML validation if your content does. That works for me.

(Example screenshot)

[RuuddM]

I would love an update on this issue as well. Besides that this issue freaks out clients and does not reflect well we are working with website which have to adhere to accessibility standards and will go through an audit which will fail based on this issue. And it seems like I'm not the only one with this problem here. Any news?

[cheestudio]

@RuuddM This is certainly frustrating, and it sucks even more to have to do this: but if you use LiteSpeed cache, you can aggregate inline CSS to a file in the and it will pass audits and validation. I imagine WP is going to need to address this rather soon, since it is now happening on all sites that use Core Blocks. I'm stunned at the sloppy and amateur implementation of the Block CSS.