CSS Linting: Bricks variables not being fully loaded when one value is invalid

[thebizpixie]

Browser: Brave Version 1.73.105 Chromium: 131.0.6778.265 (Official Build) (64-bit)
OS: macOS / Windows 10
URL: N/A

Overview
The absence of error checking or validation on variable values (syntax checking at a minimum!) means that one typo can break a large portion of the variables, with no easy way to figure out where the issue is.

Expected behaviour
If a variable value is invalid, it will be ignored and not included in the list of variables, allowing all other variables to be loaded successfully.

Actual behaviour
If a variable value is invalid, it is included in the global-variables.min.css file as is, resulting in any variables that come after this variable failing to load in the browser.

Steps to reproduce

1. Set up a site with a number of variables (at least 10) defined via the Global variables manager.
2. Enter an invalid value for a variable at about position 5 .e.g. leave off the closing bracket for a var(–xxxx) value.
3. Create content via the builder that uses one of the variable values past position 5 in the list (depends on how the file is written as to which ones will be before or after the invalid value). All variables will be available in the builder, regardless of validity.
4. View this content on the front end.
5. Inspect the element and view the variable that has been applied, and see that it is undefined.
6. View the global-variables.min.css file and see that it has all values included, but that…
7. The browser does not recognise any of the variables past the invalid one.

I have spent HOURS trying to figure why my variables were not working, only to finally discover via Firefox, which actually shows the broken CSS (unlike Brave) that there was an invalid value halfway through my variables list.

This was causing half of my variables to fail, and I could not figure out what the issue was. I expected the new variable manager to be more fault-tolerant than this, and there was no alert anywhere about my error that could have allowed me to resolve this issue quickly. Instead I had to resort to workarounds until I could finally track down the bug.

[timmse]

Hi thebizpixie,
Thanks so much for your report!

I moved your bug report to the feature requests/improvements category, as this is a suggestion for improvement but not a bug.

I completely agree with you that CSS linting (i.e., finding and highlighting invalid CSS) would be helpful in many places - not only in the variable manager but also within the builder’s input fields.

It would be great if you could submit this as a feature request on the idea board!

However, since this is a relatively complex feature that cannot be implemented quickly, you can use workarounds that will help you within a very short time, so you don’t have to spend hours searching for the cause.

In principle, the same applies to classes and variables: if they stop working at a certain point, it is usually due to invalid styles. Copy all variables or the content of bricks-frontend-inline-inline-css into a code editor with css linting on board (e.g. vsCode), and you will immediately get an indication of where invalid CSS is present.

Best regards,
timmse

[thebizpixie]

Thanks for your reply and everything you do to support the Bricks community.

From your perspective this may be a feature request, but for me, I still very much experience it as a bug.

Unlike yourself, I am not overly familiar with the inner workings or Bricks, so when something breaks, I don’t always know where to look when the usual things fail.

The hours that this took me were not in fixing it, but in trying things that didn’t work. It wasn’t until right at the end that I finally discovered the scope of the issue (I initially though it was just one variable not being applied for some reason), and then it took viewing it in Firefox instead of Brave to finally diagnose that it was a CSS issue.

After already having issues with loading the CSS internally and having to switch to external and constantly rebuild the files, to caching issues, Bricks has become so complex that it’s not easy for me to know where to look when something doesn’t work as expected.

I spend a lot of time working in PHP, and at least it logs its errors in a more obvious way. CSS often fails invisibly, or at least in a much harder to track down way.

Maybe it’s the fault of CSS or the way web browsers implement it, but the lack of fault-tolerance for simple single-character errors in CSS is one of Bricks major weaknesses from my perspective, especially for something with so much power and flexibility that implements everything else so well. In fact, on reflection, almost every intractable issue I’ve had with Bricks has come down to undetectable CSS issues.

This was my first time using the new global variables manager, and I trusted that it would give me additional functionality that made it worthwhile. Now I am in two minds. It’s nice having auto-complete, but I can achieve the same thing by adding variables with empty values, and then specifying the actual values in a faster to access and debug list in my child theme’s styles, which I would rather not do, but for now it seems like a safer option. With the lack of error detection, I’m not sure which way I will go from here.

Don’t get me wrong, I absolutely love Bricks and I will continue to use it for every site I build because of its flexibility and power, but the reason this remains a bug for me is that I honestly expected it to handle this much better than it does, especially given the way it handles everything else, and the fact that it allowed me to make an error and not notify me of it is very much a flaw, not a “nice to have”.

I will also add it to the idea board as you requested.