Customiser CSS in footer

[Stuart]

The customiser is writing CSS to the footer which is causing a validation issue ( ‘Element style not allowed as child of element body in this context.’ ) is there a way to remove this or have the styles written correctly to the header?

<style type=”text/css” id=”tribe_events_pro_customizer_css”></style>

[George]

Hey Stuart,

Thanks for reaching out!

At this time, there isn’t a way to remove or move those styles—that being said, they style tag also shouldn’t cause any actual problems with the rendering of your page’s markup. Will it be flagged in a diagnostic tool? Sure. Will this cause any actual problem? It normally will not.

This is definitely worth investigating, though, and I will flag this as something our developers can explore as a potential bug.

In the meantime, can you share a bit more information to help us get a sense of the issue here?

1. It sounds like you aren’t actually using the Customizer to customize your Events Calendar elements. Is this true? Or are you using the customizer to, say, change colors of some calendar elements on your site?

2. What specific diagnostic tool are you using where that notice pops up, the one that reads, “Element style not allowed as child of element body in this context.” Share a link to this tool if it’s an online one.

Thank you!
George

[Stuart]

We are not presently using the customiser .

Problem is that we need to demonstrate validation via the w3c validator: https://validator.w3.org which has issue with the use of <style> in the the html body.

[George]

Hey Stuart,

Thank you for following up. I investigated this with a developer and we have confirmed that there is a bug here where those tags are showing up even if there are no Customizer styles. We do not intend for this to happen—those tags should only ever load if there are actual Customizer styles.

I’m sorry about this! We will work on a fix for this for a future maintenance release.

---

As for why the tags are outside the document HEAD in the first place, this is unfortunately because we’re in a bit of a Catch-22 with how to generate those styles. Let’s assume there were Customizer styles on your site—if we stuck to HTML standards and put those styles in the HEAD, then what we’ve found is that the styles often get overridden by other styles on the page that come after that.

Folks complained, rightfully so, so we moved the styles even lower on the page to ensure they “stuck.”

The style tags outside the HEAD is supported by all modern browsers without issue. But it’s technically not valid, so yes, you will have the validation errors you discover….

I just wanted to give some backstory there. It’s a bit of a “damned if you do, damned if you don’t” situation, but we’re working on a better solution for this.

---

In the meantime, if you do not need to use Customizer styles, then you should be able to remove those tags altogether by adding the following code snippet to your theme’s functions.php file:


add_action( 'init', 'tribe_remove_customizer_style_tags' );

function tribe_remove_customizer_style_tags() {
remove_action( 'wp_print_footer_scripts', array( 'Tribe__Events__Pro__Customizer__Main', 'print_css_template' ), 15 );
}


That should remove the tags from your document, thus allowing for validation. (Or rather, it will remove this one thing that is in the way of validation–if there are other issues with your document not related to The Events Calendar, those issues are separate from this).

Cheers,
George

[Stuart]

This reply is private.

[George]

Give this a try instead; if it fails, then waiting for a future release is indeed the next best option:


add_action( 'init', 'tribe_remove_customizer_style_tags' );

function tribe_remove_customizer_style_tags() {

if ( class_exists( 'Tribe__Events__Pro__Customizer__Main' ) ) {
remove_action( 'wp_print_footer_scripts', array( Tribe__Events__Pro__Customizer__Main::instance(), 'print_css_template' ), 15 );
}
}


[Stuart]

This reply is private.

[George]

😀

[Author]

Posts