Archived topic
Customizer CSS Bug?
13 replies · Started by Matt Stern on April 2, 2022
Hi guys,
We notice that when editing Simple CSS panel in the Customizer, if we delete or change any character in the css, the preview on the right moves around and gets a bit wonky, even if the css deleted is not related to the part of the page being previewed.
It doesn't seem to affect anything on the front end, which is great. But it has my client nervous. :)
I made a quick screencast demo: https://vimeo.com/695234647/4207525518
Let me know what you think.
Thanks,
Matt
Hi there,
to calm your clients fears - i cannot see this being an issue at all.
It looks to me that invalidating that line of CSS is causing the Javascript driven customizer preview to have a bit of a meltdown. Do you have a LOT of CSS in the Simple CSS ?
Around 1700 lines in simple css. :/
Oh wow - yeah thats a LOT of CSS lol - i would consider that enough to give the customizer scripts a hard time.
You may want to consider moving that into a Child Theme if possible just because of front end performance thats a lot of CSS to be loading in the head. Unless you're using some optimizers to save it out to an external file.
:). Ok I’ll plan to create a child theme. Then I just move the css in simple css and additional css to the new style.css file?
I didn’t realize that css in the customizer could cause front end performance issues. Does css from style.css get loaded differently?
What’s the recommended upper limit for css lines in simple css?
Then I just move the css in simple css and additional css to the new style.css file?
Thats correct.
CSS added in Customizer > Additional CSS or in Simple CSS are:
a) saved in your database - so require additional database queries.
b) printed inline into the <head> of the HTML document. So it increases the page size of every page load.
c) NOTE: both of the above stop being an issue if optimisation plugins are being used to combine and cache inline CSS...
Whereas styles.css get loaded as a file, so it incurs additional network requests, but they can be cached by the browser and therefore only loaded once on the first visit.
With modern servers, browsers and computers nowadays having 1700 lines of inline code is probably not an issue. But the Customizer technology is quite old and its JS rendering is bit janky. Ultimately for me - i find it far easier to maitain that amount of CSS outside of the Customizer. And for that reason Tom and I agreed on a max. 400 lines of CSS in the Customizer for any site i built for the GP Site Library. And i kinda stuck to that limit now.
I appreciate the explanations, David. As far as organizing the CSS, is it possible–or recommended–to separate the css into different files? So perhaps woocommerce related css would have its own files separate from style.css?
Thanks again,
Matt
If you have a lot of Woo styles then adding them to a separate stylesheet makes sense from organizing and portability.
If you want to do that then you could:
1. Create a /woocommerce directory in your Child Theme and your Woo specific style.css inside.
2. In your child theme functions.php use the following snippet to enqueue that stylesheet when you're o
function register_my_woo_styles() {
if ( ! class_exists( 'WooCommerce' ) ) {
return;
}
if ( is_woocommerce() ) {
wp_enqueue_style( 'my-woo-styles', get_stylesheet_directory_uri() . '/woocommerce/style.css' );
}
}
add_action( 'wp_enqueue_scripts', 'register_my_woo_styles' );This will only enqueue the style sheet if woo is active ( stop errors throwing ) and if your on a woocommerce template.
That's awesome, Thanks David.
Ok one last question...when we install the child theme, will we lose our customizer settings? (Besides Simple and Additional CSS, I know we'll lose those.)
Thanks again,
Matt
Hi Matt,
To answer your question, no, except for Additional CSS, you wouldn’t lose your customizer settings when you decide to use a child theme.
In any case, you can also Export/Save a file of your current Customizer settings in Appearance > GeneratePress: https://share.getcloudapp.com/2NuzPxDe
This applies to all customizer settings. It doesn’t include any content, including Elements or Additional CSS in the Customizer. This would assure that you'll have a backup of your current customizer settings.
Hope this clarifies. :)
Hi again guys,
So I got the child theme setup, and moved css from Simple CSS and Additional CSS into the new style.css file.
Trouble is, some of the CSS no longer works. If we add !important to a given line, it will work, but I understand that this is not best practice.
Is this a common problem and do you have any suggestions?
Thanks kindly,
Matt
Trouble is, some of the CSS no longer works. If we add !important to a given line, it will work, but I understand that this is not best practice.
It sounds like your CSS is overriding each other, it's not a common problem. The easier way would be adding !important to some of the CSS, but the better way is to exam every line of CSS to make sure there's no duplicated CSS overriding the other.
hmm, but if my own css were overriding itself, wouldn't the problem have been present when I was using simple css? Maybe I'm missing something.
They were in different style sheet with certain order, so yes, they were overriding each other, but in a way that "looking good" on frontend.
Now they are in the same style sheet, but the order might've changed.
If multiple CSS targeting the same element with same priority, the later one will override the ones added before it.
