WIP: Style Manager: CSS Variables do not show Edit options (Rename, Categorize, Lock, Duplicate) when selected individually (issue exists prior to 2.2)

[datgausaigon]

Browser: Chrome - Version 143.0.7499.170 (Official Build) (64-bit)
OS: Windows 11

In Bricks Builder versions prior to 2.2 (beta) and continuing in 2.2 (beta), CSS Variables inside Style Manager cannot be edited individually via the UI, unlike CSS Classes.

This is not a new regression in 2.2, but an existing issue that remains unresolved.

Current behavior:

• In Style Manager → Classes:

  • Selecting a single CSS Class displays full edit options:

    • Rename

    • Categorize

    • Lock

    • Duplicate

• In Style Manager → Variables (all versions before 2.2 and still in 2.2 beta):

  • Selecting a single CSS Variable:

    • No edit options are displayed

    • No UI controls for Rename, Categorize, Lock, or Duplicate

• Evidence that edit functionality already exists:

  • When selecting multiple CSS Variables using Shift + Click, the “Replace” (bulk rename) option appears

  • This confirms that:

    • Variable renaming logic is already implemented

    • The issue is related to missing UI exposure for single selection, not lack of capability

Why this is a bug (not a feature request):

• The functionality already exists (bulk rename) and in CSS Classes

• The behavior is inconsistent with CSS Classes

• The limitation has existed across multiple versions, indicating an incomplete or missing UI implementation

→ VERY HARD TO EDIT A CSS VARIABLE!

Screenshots:

1/ The Edit Panel of CSS Class in Style Manager:

2/ The hardway to edit name (rename) a CSS Variable in Style Manager:

I hope this will be improved in version 2.2 GA.

Thanks

[Matej]

Hi @datgausaigon,

to me, this looks like a improvement request, so I’m thinking about moving it to the correct category.
However, before I do that, I just want to make sure that I understand the issue correctly. AS far as I see, there is no bug/problem, but only that the side panel doesn’t open, if it’s only one variable selected. And because of that, when you select one variable, you have to rename it inline, not via right panel?

Is it that, or am I missing something? Let me know, and I’ll create an appropriate internal task.

Best regards,
Matej

[datgausaigon]

@Matej

to me, this looks like a improvement request, so I’m thinking about moving it to the correct category.
However, before I do that, I just want to make sure that I understand the issue correctly. AS far as I see, there is no bug/problem, but only that the side panel doesn’t open, if it’s only one variable selected. And because of that, when you select one variable, you have to rename it inline, not via right panel?

Is it that, or am I missing something? Let me know, and I’ll create an appropriate internal task.

Hi @Matej

Thanks for taking a closer look and for checking with me first.

Yes, you’re right that variables can currently be renamed inline. However, my concern is less about whether renaming is possible, and more about the editing experience and UI consistency.

In particular, renaming via a dedicated input field (textbox) with an explicit “Save changes” button provides a much clearer and more reliable workflow:

• It makes copying, pasting, and selecting text significantly easier

• It avoids accidental edits

• It clearly communicates when editing starts and when changes are applied

Inline renaming, while functional, feels limiting in comparison—especially when working with longer or structured names.

For CSS Classes, the right-side panel already offers this kind of structured editing experience (Rename, Categorize, Lock, Duplicate), which makes managing them more comfortable and predictable.

Additionally, since the Replace option appears when multiple variables are selected, it seems that the variable editing logic already exists — it’s just not exposed when a single variable is selected.

I’ve also noticed the same behavior when renaming Elements in the Structure panel, where renaming is limited to inline editing as well. This suggests a broader UI/UX inconsistency rather than an isolated case.

Because this behavior has existed since before version 2.2 and introduces inconsistency across different parts of the UI (Classes, Variables, Structure panel), I wanted to report it so you can decide whether it’s better treated as a bug or an improvement.

Hope this clarifies what I was trying to point out. Let me know if you need any additional details.

Thanks

[Matej]

Hi @datgausaigon,

thank you for the response. I’ve decided to move it to the Feature Requests / Improvements , because nothing is broken per se.

But, I agree that we should make this consistent on both classes and variables. So, I’ve created an internal improvement task for this.

Thank you,
Matej

[datgausaigon]

Hi @Matej @timmse,

First off, I am currently testing the 2.4 Beta and really appreciate the overall progress and new features. Great work!

However, I am a bit disappointed to see that a specific UX inconsistency in the Style Manager hasn’t been addressed yet. As I have mentioned previously, the CSS Variable manager desperately needs a dedicated Edit Panel (with Rename, Categorize, Lock, Duplicate options, etc.) for all variable types.

Currently, [Color] variables are handled perfectly. When selected, they reveal a full-featured edit panel that includes the RENAME function and a very useful MANAGE (COLOR PALETTES) redirection button.

But this UI parity is completely missing for other categories:

1. Standard CSS Variables: As shown in my first screenshot, custom CSS variables (like --foo) completely lack this edit panel.

   

2. Spacing & Typography: As shown in my second screenshot, variables from the [Spacing] and [Typography] categories are also missing the edit panel and their respective management buttons.

   

Expected Behavior & Feature Parity:

• Edit Panel Access: Clicking on any variable type (Standard, Spacing, Typography) in the Style Manager should open the right-side Edit Panel to allow basic operations like Rename, Categorize, Lock, Duplicate options.

• Contextual Manage Buttons: Just as Color variables have a MANAGE (COLOR PALETTES) button, Spacing and Typography variables should feature their own respective management buttons (e.g., MANAGE (SPACING SCALES) or MANAGE (TYPOGRAPHY)) to quickly navigate users to their root configuration areas.

Bringing this level of UI parity to all variable categories would massively improve the workflow. Could we please get this implemented before the stable 2.4 release?

Thanks,