V4: Make Variables Manager More Flexible

[ericwang401]

Describe the Problem

Elementor’s Variables Manager currently can’t store unitless numbers (e.g., 1.4). That’s a problem because unitless line-height is valid CSS

Right now, if I want to implement a set of constrained values for typography, I have to hardcode line-height per text size in every element, which is super annoying, very easy to desync, and mistype values too.

Also, the Variables Manager feels like it’s trying to validate inputs into arbitrary categories (e.g., color, font, size). But really, CSS values are much more diverse, and there are so many more perfectly valid values that this validation excludes, so this validation mechanism ends up restricting a developer's flexibility.

Propose a Solution

1. Let size variables store unitless variables

2. Stop hard-blocking values based on variable categories.
   The UX of the categories is nice. For example, the color wheel is great whenever the value is actually a color, but that shouldn't make it gatekeep other color values.

3. Implement folders to help organize variables instead of categories
   The current system gets difficult to navigate as you create a lot of variables. Consider Figma's approach with accordions.

To further illustrate why a whitelist of values is restrictive, we currently have all of these possible values:

• Colors: lab(96.52% -0.00003 0.00001), color(display-p3 1 0.5 0), color-mix(in oklab, var(--primary) 70%, white), oklch, etc
• Sizing: clamp(1rem, 2vw + 0.5rem, 1.5rem), calc(var(--base) * 1.125) (DON'T forget you can even reference variables within variables)

If ya'll want to keep categories for UI purposes (like automatically pull up a color wheel for convenience), that's great just think about making the UI assistive and not restrictive. For example,

• Accept any raw string value
• Show color picker if the value is a valid color
• Show a slider if it's a length/number (just an example, I would most likely not use this because of how imprecise sliders are—if I'm already making CSS variables, I'm already looking for precision, which defeats the purpose of this slider)
• STILL allow saving even if it doesn't parse. Treat it as a raw CSS token because honestly it's going to be really difficult to account for every single shape or form of value.

Additional Context

A workaround is by creating class names. I'm coming from the world of Tailwindcss, so I would create text-base, text-lg, etc.

However, an issue with class names is that it's not responsive to breakpoints. This will be filed in a separate issue as it's also very annoying. Overall, it’s infuriating that Elementor advertises “developer tools” (class names, CSS variables, etc.) but then hard-limits them so much that they share the name, not the capability.

PLEASE dogfood your own product more. I see ya'll used Elementor for Elementor's landing page, but I can't imagine ya'll must've not encountered similar problems.

Agreement

• I confirm I have read and followed all the guidelines and instructions outlined in the Feature Request form.
• I agree that my discussion may be closed without further action if it doesn't meet all the requirements outlined in the Feature Request form.

[sanholo177]

Agreed. The name is not enough, we need the capabilities. I had been waiting for classes to use oklch for all our design systems, but due to limitation on responsive classes and variables, we don't think we will move across to v4 just yet.

[ericwang401]

Yes!

...we don't think we will move across to v4 just yet

Wait to clarify, does v3 support responsive classes? I didn't find anything online about this but lmk