In the bricks settings, I set the css generation method “External files”. But on the frontend, I see that bricks writes inline styles for my classes. Why doesn’t it put them in a file? I would like my html to look cleaner. Considering that I am writing a very large number of styles for the project, there will be a large layer of inline styles in html. What to do so that the styles are written only to the file? Thx
try to regenerate CSS.
Bricks → Settings → Performance → “Regenerate CSS files” Button
It did not help. After regeneration, the styles for my classes are written inline directly in html.
Here is a test link (Sample Page – Try Bricks – t6966007). You may notice that the styles for a class like (.scroll–container) are written in html and not in the post-2.min.css file
I believe this is due to the fact that we are creating a global class. But why not put these classes, say, in the global.min.css file and include them on all pages?
If I write for example 100+ classes, then my html will be bloated in the current situation.
Or am I misunderstanding something?
Thanks for pointing this out, @Lkey, I just checked one of my sites and see the same - Someone with more development knowledge will hopefully point out why these are added inline.
I would have thought that instead of adding all the custom classes to a global file and bloating it, wouldn’t it be better to add the CSS to the post.css file specifically for that post to help keep unused CSS at a minimum?
@timmse Sorry to tag you in on this; it is logged under a ‘How to,’ so appreciate this would take a lower precedence than bug submissions and something you might not keep an eye on, but is this how it should be and is this optimal and if not should a feature request be created?
Well you are right. It should be done bit different.
I think better implementation will be after introducing “global class manager” which is in roadmap.
Sorry for my English.
Thanks for the answer. I’m new to the forum, not quite sure how to format my question.
Michael. Yes, that’s what I was talking about. file that contains custom styles for this page. We create post-*** And I thought that when specifying css generation, all styles would be written there. But I see something else.
timms. I understand that inline styles optimize the page in their own way. I understand that bricks is a builder that simplifies writing styles. But as a former designer, I will say that styles are very important. I ask you to consider putting the styles in separate files.
I try to do awwwards level work. My desire is that the site on bricks be on the front page.
Thank you for your quality work and feedback.
No need to apologise, I think you explained it very well
I have checked the website source code of Zion, O2, Ele, and Breakdance, and none of them puts the breakpoints as inline styles. I am not a CSS delivery optimisation specialist but cannot find any content on the big G that advocates this, making me think it might be a bug or a feature request?
I will move this over to a bug ticket. This way, it can either get a fix or an explanation as to why and the benefits, but at least there will be an outcome.
Was also mentioned in the FB group aswell:
P.s. Welcome to the forum
Welcome to the forum and sorry for the late reply!
With Bricks 1.7, the first step is done. We’re providing a setting to disable the class chaining, please see the changelog: Releases – Bricks
Quote from the changelog:
If the feedback is positive, the next step is to provide one global class CSS file (when using the external file CSS loading method) rather than loading those rules inline.
We still get Inline CSS put in the head.
The option to put css in an external file is not working?
It’s not removing the inline CSS from the head.
Your question was answered in the comment above,…
“If the feedback is positive, the next step is to provide one global class CSS file (when using the external file CSS loading method) rather than loading those rules inline.”
Can someone explain why there is inline CSS on page when the setting is set to use External Files?
I don’t quite understand why some CSS ends up in post-XX.min.css and the rest is thrown into the page.
Hi a ll, any news on this one?
@timmse hi, and where can we provide feedback exactly?
I just realized that the complete theme styles css is loaded in the head of each page (in addition to other css, like AT’s).
Does it make much sense like this?
How is this still an issue, the global class manager was added, and I still get nearly all of my CSS inlined on the page + all the other CSS files.
I can’t imagine why you’d want all this duplicated, and its causing issues with css somehow loading default styles after custom classes, causing random defaults to override my own class settings.
We do 100% custom classes, so that pretty much means every page is bloated.
I’d also like to know why global classes should be generated on a per page/post basis, rather than globally saved once and loaded on all of them to take advantage of caching.
@danieliser well it seems that the so much anticipated “global class manager” is pretty useless. I was expecting something to more or less MANAGE my classes. Its nothing like that sadly.
C’mon, serve the CSS in an external. That’s what the setting is for right?
Please implement this, I feel like that using a class system will create a huge amount of unminified unoptimized inline CSS.
Sorry for the late reply and for the delay in implementing the improvement mentioned here.
We know the importance of this improvement, and it is still on our to-do list. Rest assured that we will endeavor to provide an update as soon as possible. We appreciate your patience!
PS: The class manager feature isn’t related to the generation of styles (inline/external).
If you have any problems (bugs category) or suggestions for improvements (improvements category) for the class manager, please let us know in a separate thread. We are grateful for every suggestion, even if we rarely answer within the improvements category. However, this does not mean that we do not read the suggestions and take them up if necessary.