namithj
commented
1 year ago Aint this already possible using is_page_template() within wp_enqueue_scripts action while registering the scripts?
Open Rale379 opened 1 year ago
namithj
commented
1 year ago Aint this already possible using is_page_template() within wp_enqueue_scripts action while registering the scripts?
Rale379
commented
1 year ago @namithj
Of course, what you're saying is possible, with PHP and for advanced users.
This is more like a convenience feature.
This adds inline code to the page, which is kind of a bummer.
Would be nice if it created a minimized CSS file.
Actually, that would be amazing!
Otto42
commented
1 year ago On a test site with a default theme setup. I get this in the body tag.
<body class="home blog logged-in admin-bar no-customize-support wp-custom-logo wp-embed-responsive">
Similarly, there are numerous automatic classes added to pretty much everywhere. Making things specific to a page or a template, or whatever is easily done with these class selectors.
So from a functionality standpoint, this type of selection is already easily done.
What you are proposing here is for there to be a second CSS selection when the template or page, or something like that, which inserts that CSS only onto that page or whatever. This means adding queries to retrieve the metadata and display it, as well as the UI necessary for entering that CSS.
Now, while this could be done, it's not a Gutenberg issue as such. It's a more generalized WordPress issue to support having per page/template CSS. Additional PHP based functionality would be required to load and pull that data to be inserted into the page.
Personally, I don't think it's worth it when this CSS is all inline in the first place. However, regardless of that, it would be an issue that you probably should discuss on the core trac first, as it requires adding a new system to WordPress itself, rather than just Gutenberg for the UI.
Rale379
commented
1 year ago @Otto42
1) If taking into account the Facebook post a made about this, this is the third time that someone suggested that what I am talking about can be solved by adding classes or not having the targeted classes on the page. The issue is that the browser will parse all the CSS, regardless of whether it will be used. This means that loading on every page styles that are specific to each of my 11 templates, means loading pure bloat.
2) Templates, template parts and this Additional CSS section are found in Gutenberg. Not the Customizer's box for adding CSS is the same thing… Could be. In which case, you might be right. But, as I see it, it's a Gutenberg feature and UI, and should probably be handled by the Gutenberg team
3) “Personally, I don't think it's worth it when this CSS is all inline in the first place!” I don't understand your point. However, I do think that it would be so much better if this would create auto-minimized CSS files. Because then we have other performance improving options, such as caching, asynchronous loading, deferring, preloading and / or delaying
What problem does this address?
The blocks are very basic. We need more control, especially for responsive designs, not to mention animations...
If you're adding all that CSS globally, you're bloating the site.
The default theme has 11 templates.
Each template and template part heeds its own specific set of CSS rules.
What is your proposed solution?
My suggestion is to add a tab for Local CSS, so that you may choose, whether your CSS should be loaded globally, or only for that specific template or template part.
While on the topic
Would like to see something similar for JavaScript as well. Would require a lot more options, though... Like: defer / async, load in head, body footer, add ID, etc. Is that a possibility? Should I create another suggestion?