Some feedback on the 1.9.8 beta update when using the new variables manager. When you enter in a variable name of ‘Dog Over The Moon’ the variable will be ‘–Dog Over The Moon’ which is invalid. It would be good if it had validation like making it lowercase and replace spaces with hyphens.
I think it would be perfect if there were two more functions to each CSS variable. One being label and another being conditional usage.
With label if you have a variable name of ‘–lg-sec-padding’ you have to find it by that name, I think it would be good to a label on it like ‘Large Section Padding’ that way it is more readable and anyone of the project knows about it when using search, this can be an optional input field.
For conditional usage I mean like how classes work. It only loads the variable on the frontend if used on the page. As for instance I could have 50 variables created but could only use 20 on one page and 5 on another so you may not need it to render in the root all 50. But I think this is best as a toggle as some advanced users may use some variables in their own custom CSS files so should be rendered on every page, while they may want other variables to load only if it was used on that page. I hope that makes sense.
Hi Perks,
Thanks for your feedback. I have moved the thread from the Bugs category to Feature Requests/Improvements as it is not a bug report.
Currently, there is no variable name validation. If you add an invalid name (that contains spaces that are not valid), you’ll get an invalid variable. Apart from that, variable names do not have to be lowercase across the board or separated by hyphens. camelCase is just as permitted as underscores.
The valid naming for a CSS variable should contain alphanumeric characters, underscores, dashes. Also, it’s worth mentioning that CSS variables are case sensitive.
My personal opinion on the other two topics:
As for the label, it depends greatly on the naming convention you or your team choose. If there are fixed rules for it, it shouldn’t be too hard to type “lg”, “sec”, “pad”, or “sec-pad” to find the corresponding variable quickly. I’d say it’s faster than typing “large section padding”
But you could just as easily call the variable --large-section-padding. The only question is whether you want a slightly shorter variable name or one that is easier to understand.
Conditional logic: This would require a disproportionate amount of programming effort (and lead to potential problems in certain cases) but would have no measurable influence on performance (or other areas).
As I said, this is my personal opinion. Thanks again for your input! As this is a new feature, we are collecting feedback for the time being
Hi @timmse,
Thanks for the feedback . To be honest, I forgot variables were case-sensitive, you normally see them lowercase out in the wild.
I do think labels would be essential to add in my opinion, for instance you can have a category of padding that has variables with labels of button small, container small, image small, and their variables be like --brxe-pad-button-small or --brxe-pad-container-small (using a prefix in the example for good practice to avoid overlap) but ultimately it is easier on the end user to grasp quicker and when returning after many months to do updates. Just my 2-cents.
Overall my initial usage of CSS variables manager is very good in terms of ideas for usage. I have a bit of a creative block when using Bricks most of the time unfortunately so I tend to go and use the free Elementor page builder to create a quick wireframe and then recreate with Bricks but I can see this helping a lot when mapping out a flow. I think once components get released soon I can better adopt Bricks.
Also as a side note if possible (likely not for recent future updates) I think it would be great to have a raw input option for font family and weight dropdowns so it can accept variable inputs in some fashion. I think that would help cover some peoples use cases I think.
Hey @timmse,
Me again, sorry. About the labels point I made. I just thought it could be thought up the same way as the dynamic tags. Why search by the dynamic tag like {post_id} or {post_title} when it is labelled as ‘Post ID’ and ‘Post title’. It is just easier visually. Especially when you can have so many.
. To be honest, I forgot variables were case-sensitive, you normally see them lowercase out in the wild.