I have a page that contains an h2 tag with the class page-lead__heading. It render as it should.
the class contains a font-size: var(–text-l) and a color: var(–accent) there is more but enough for this example.
I am now adding blog posts via the Gutenberg editor and am adding the same class to an h2 via the advanced tab (without the dot). When viewing the rendered page I can see the added class but the class definitions are not found at all in the attached style sheet.
They are however visible in the static page that uses the same class.
Is than an error or is there a setting that I changed/didn’t change that prevents classes from being global?
I have regenerated the CSS via the Bricks → Settings → General Tab under Custom Breakpoints (I added one for large iPad). And checked that the disable Global Classes is unchecked (grey).
At a loss, since all of my class stylings are basically useless for the blog template.
I also tried to turn off Gutenberg (after the fact), but that didn’t change the use of it at all.
Hi Dean, thank you. Yeah, this highlights one of two issues. The reuse of classes that are not on the same type of element. (Because they are chained). And the second is the interoperability of Bricks with the Gutenberg editor. “Simple” things like editor width and loading of Bricks styles into the Gutenberg editor.
I have tried adding the exact class as its output from a page from Bricks to inline styles to the element class as well. Without success. The class is there but the style declaration is missing.
Actually, this results in a third problem: the lack of global styles. Since the Bricks styles are only output inline on any page where that class is declared, it’s omitted on any page that tries to only use the class without declaring it. That’s useless IMHO. I’ll have to test and see if the CSS as an external file option could solve this, but only if it automatically updates the output on every save.
@thomas I know you added a ton of complicated features and are working on conditions API etc, How about the ‘simple’ save to stylesheet ability that isn’t experimental? I have seen that some of the related issues with chained classes or global classes aren’t new requests or bugs (IMHO, I think they are bugs because they are fundamental to web design).
Mind going into the details fo solving that issue, timelines etc? Thanks in advance.
Hi Sebastian,
Thank you very much for your report.
The problem arises, as Dean already correctly said, through the chaining of the classes. We have the issue on our radar and will address it as soon as possible, but it is not a “simple” task that can be solved on the fly.
Thanks. I read this. And I fully understand that this isn’t a quick and simple thing and affects a lot of areas. After reading the initial response, do you have any update from two months ago on where this might lie in your plans/roadmap?
Unfortunately, I can’t say more than the roadmap itself. The task that goes along with it is this one: Roadmap – Bricks
So it will still take a while. I understand this is an important point - but it is not the only one on the to-do list, and, compared to the other requests, it has fewer votes.
Thanks for the link. I understand the voting system. But I would think ‘features’ (or rather fundamentals) that help simplify the overall system would be more beneficial to the software and its adoption, no? So the ability to manage external stylesheets (this is just because we happen to talk about it here) would easily allow outside developers to add new features that didn’t need to fully hook into Bricks and, therefore, make it easier to adopt on a larger scale.
I barely know Bricks much like the rest of you, but only working on features at the whim of its user base might not be such a good idea (my wishes included), especially when the user base grows and you really want to help that base succeed. It has the early Android approach to development, no? Either way, I’ll go vote on that ‘feature’ now.
Come to think of it, you don’t need a Manager, you already have it in WP. You just need to export to it. Bricks is a theme after all, no?
I know right? Pretty useless as a “theme builder” when you can’t use it to style arbitrary content. This combined with the many problems with the editor not rendering like the frontend just may be the final straws that force me to throw out Bricks. Another failed experiment, just like Oxygen.
Well the Global Class Manager was added, but classes still aren’t global. If you define a class of .red to give text a red color on some random page in Bricks and then add that class to another page via some other method (perhaps a page that doesn’t use Bricks for the content, or the output of a plugin), the styles you added to .red in Bricks will not apply to the .red element on the site. I find myself removing more and more styles from the builder and hand-coding them in my theme’s style.css. …You know, so it will work like a theme.
It’s ‘global’ in the sense of globally available within Bricks. ie can be used on any page or template.
But not all stylesheets are added to every page of the site, so it wouldn’t work if you give a class to something outside of Bricks.
For that to work, Bricks would need to output ALL styles on every page into one global stylesheet, just in case a class is used elsewhere, which… honestly I suspect most users wouldn’t want compared to the current conditional CSS loading which is lighter. But adding to the ideas board as an optional feature, for those that prefer that, may be a good idea. “add all styles into one global stylesheet” type feature.
Perhaps a checkbox in the Global Class Manager to allow a class to be output on every page would be optimal. This would help make Bricks more a theme builder rather than just a page builder.
Well, to chime back in here after oh so long… We do have technologies that prune css (tailwind being the most prolific) and since Bricks is working towards components this might be a better use case.
Has anyone tried to make a component with classes that are available in GB and see if that class is available on the front-end? Here I would imagine that this is an intend use of the components feature and would then make css classes available, depending whether the component’s css is loaded inline or not.
It doesn’t quite satisfy the ‘global’ (across the WP site) idea, but maybe they are moving to that component architecture that is more and more common first?
The other problem with Global Classes not being global is that we can’t use them in Code elements or any kind of generated output, even on pages that are rendered using Bricks.
We do have technologies that prune css (tailwind being the most prolific) and since Bricks is working towards components this might be a better use case.
with Tailwind, there is no “prune css”.
Tailwind generates CSS on demand: if you use one class, it produces just that one class. It doesn’t start with a large CSS file and then prune it down. Instead, it effectively starts with an empty stylesheet and only adds the classes that are actually used.
you’d be correct, but that presumes you’re using the proper building methods (rather than what I see a lot is dumping half of tailwind into a static file) and wasn’t (at the time of writing this) not the point. The point I was making back then is that the classes would be removed if they weren’t in used in Bricks. So a class set up in Bricks, but the element removed and the class still used elsewhere would remove the class… And my question then was to see how Bricks then handles css on a component basis, much like other component frameworks do.
A bit of a chicken and the egg thing. How does one solve both scenarios? I have not used Bricks in this regard, so I would have to test it before making any claim. This was an issue with a much older version and Bricks has had major upgrades since.
But yes you are correct, when tailwind is set up properly and then built it would only include classes that are actually used.
Tailwind also can’t just dump something into a static file. As I said previously, Tailwind starts with an empty stylesheet. If you don’t use any classes, nothing will be generated, so there’s no way you could end up dumping half of Tailwind into a static file.