I’m wondering if you add the breakpoint to the up and coming component or use container queries could help to solve the problem. My idea may not work depending on the numder of elements used but that’s up for debate.
Also wonder if this type of feature can be added to the Global Class Manager where if needed you could define your own %my_variable% variables which could pull its data using PHP.
Maybe even some sort of echo function like templates have %echo:my_custom_function%
Still with the echo function I would rather assign it to a %% variable in case I use it in multiple locations and something needs to change. (one source of truth)
Maybe WPCodebox can add a layer that does the conversion to CSS in the background. I think there was already a request like that recently. I’d also implement more necessary features in Bricks, like Global components
This would be a really useful feature and something that keeps me from using Brick’s custom css input box. I would also really like support for container queries added.
If you’re intention is to create a shortcut “on the fly”, this is really easy to implement. But if you want it to act like a global variable that will be updated on all pages whenever you change the breakpoint value, that’s not straightforward.
Not exactly the same as what is being asked for here…, but I’m just adding this info here in case it’s relatively unknown… Bricks already automatically updates the media query px value whenever you add custom CSS, as long as you add in the custom CSS while that breakpoint is selected in the builder. (rather than writing out the seperate @media (){} for each one)
Simple example… I add custom CSS to make the background turn green on the ‘tablet-portrait’ breakpoint. If in the future, that tablet-portrait breakpoint px value is changed on the site, it will also change for all the custom CSS that has been added in this way. Doing it this way, the values aren’t hardcoded into the CSS, it’s dynamic based on global settings.
I was about to say this TBF lol. I always use this and then rely on me just selecting the size. It’s a change in workflow to a degree, but you can then see what the results look like unlike using the media query on another screen size setting. Otherwise, might as well use WPCodebox.
I guess none the less though, Kevin’s suggestion wouldn’t hurt and would improve workflow for those wanting to use that.
Wouldn’t it be very similar to SCSS? You create variables for each breakpoint and map the breakpoint values to them, then the parser in Bricks will output the correct value based on the token used…
Because that’s not how bricks works right now. All the css written in the control is parsed (and saved) as plain CSS. The %root% is not a variable, it doesn’t store any value, it just replace the string to id/class on the fly, but in the database it’s saved as plain css. What you are after is a way to use variables inside css, which works in a scss environment - not a plain css one. So either Bricks implement scss inside the css controls (which isn’t easy) - or save all your css twice: one version including your variables, and a plain one to render inside the builder (both should be continuously parsed on the fly on all your elements on all your pages - that’s resource consuming). Either way it’s not straightforward.
I was surprised at how you said it worked, after a quick test by using the actual css class name in the css panel and saving the page and then refreshing the editor I see that it gets converted to %root% so it appears you are right …
Adding this feature in shouldn’t be to that much extra work though. The Custom CSS panel is just one input amongst a pile of other individual styling inputs in the Bricks Editor that all have to be parsed and compiled into style sheets (or inline within the HTML ) that can be used when the page is saved in the editor. So storing an extra copy of the original custom CSS and parsing it for custom variables shouldn’t be difficult to do.
