The parsing doesn’t take place when you save the page, it does each time you digit any key inside the control field, so it can correctly render inside the iframe. It’s not just “one field more in db”, it has a resource cost, both space and memory usage. It’s doable. It might be worth it for some users. But it’s not something you implement in 5 minutes. And since breakpoints involve all the pages, you’ll need to add the calculation each time you load the page on frontend.
Forgive me for being dumb and slow, but if %root% can expand to [current-class-name] on the fly, why can’t %breakpoint-m% expand to [breakpoint-m-value] on the fly?
Doesn’t %root% have to get the current class name to know what to expand to? It seem like it could get the current breakpoint-m value just as easily?
I believe what you’re saying, I just haven’t taken the time to inspect the situation so I’m trying to understand better.
if you’re looking for an “on the fly” shortcut for breakpoints - just like %root% does - it’s super easy to implement and has zero impact on performance/database. But that’s not what you’re looking for, cause breakpoints are a global value, if it changes at some point, you want it to be updated on every element that uses this shortcut, right?
The %root% doesn’t have the same issue, it’s targetting the current element that you’re modifying, it doesn’t require to involve other elements or other pages, and it’s either translated in a class or an id.- both are strings. So the direct parsing of the value is enough.
if you write %root%{color: red}, it will be saved as .my-class{color: red}, and the parsing is finished, the value is saved to the db, job done. On frontend you just echo the string, and the css is rendered.
Now if you use:
@media and (min-width: %bp-xl%){
…
}
it will be translated to:
@media and (min-width: 991px){
…
}
that’s now a static value.
If you now change the breakpoint value, there is no way to easily change 991px on ALL the elements, and on all the pages. 991px isn’t a variable.
If you want it to act as a variable, you’ll have to save this in db:
@media and (min-width: %bp-xl%){
…
}
and parse it for each element on each page. This has to be saved as a dynamic value… And since it’s dynamic, the parsing needs to involve all the elements of the page (to render correctly inside the iframe as plain CSS), and each time you load a page on the frontend.
Makes more sense now?
3 Likes
Yep, thx. I guess since class names can be edited and the %root% is able to continue parsing everywhere even after editing the class, that it might be similar for breakpoints, but I see the distinction.
I imagine it would be tricky to set something up that can reference people’s Bricks breakpoints since they can be set to anything, with any number of them, along with mobile/desktop first approaches. Having an SCSS options in the CSS fields where we can @import from a local SCSS link like “/wp-content/random-place/mixins.scss” would give us the option to at least reference breakpoint mixins within our own styles that we’ve already set to match the Bricks breakpoints (including ACSS).
But, if Bricks ever does add SCSS support, please, please, please include Autoprefixer support since most script managers don’t offer that. Cwicly includes SCSS support with Autoprefixing, so I know it can be done!
I understand what you are saying and agree on how it would need to be saved, but how does Bricks handle a Global CSS Style name change. From my understanding Bricks stores classes as an ID in the database. This way classes are centralized but with the class name being hardcoded in the custom css this would mean on a class name change, Bricks would have to go in and update all the custom css of elements that use this class since the class names in those are actually hard coded.
I also understand this is not a 5 minute change, I meant it’s easier compare to some of the other Bricks Feature Requests I have seen.
Also some of those resource issues could be refined… for example parsing only after changes happen and the cursor goes to a new line or something… (instead of after every change or addition of a character)
Or maybe at this point it is better to consider implementing a framework within Bricks so a CSS processor could be used. Bricks could have a simplified one for things like this request or you could choose SCSS or something. Maybe this is a new attribute in the panel and is more of a code window (or what ever makes the most sense).
1 Like
On a class change/rename action - which in vanilla Bricks can only be done while you’ve actually selected that class and is active on the builder - the script doesn’t have to make changes to other elements/classes. The hardcoded css uses a .replaceAll() function to replace the class name with %root%, and that’s it (since the %root% is targeting only the active class/element). It looks like a variable, but believe me it’s not. It’s just a « string » shortcut. And that’s basic stuff. Dynamic breakpoints in a plain css context is a another story… it’s doable, but that would lead to adopting a different method to store/parse and render the css styles compared to the actual way of dealing with it.
2 Likes
Please just find a way to at least give a hook so Automatic CSS can get it and offer us a token