FEEDBACK: Cascade layer toggle contradicts UX best practices in 2.0

Feature Requests / Improvements
1

Standard UX practices for toggle switches dictate that a toggle switch in “ON” positions means something is enabled. The cascade layer toggle in 2.0 violates this and introduces significant confusion in 3 ways:

  1. ENABLING the toggle DISABLES the feature: This is counterintuitive and requires too much thought to try and understand what is actually being enabled/disabled. On should be on, off should be off.
  2. The “discouraged” note adds further confusion: Is it discouraged to activate the toggle or discouraged to deactivate it?
  3. Reversal of toggle behavior from v1.12.4: This new toggle is in the exact same position AND has the exact same section heading (“Cascade Layer”) as 1.12.4, however the behavior is the exact opposite. 1.12.4 ENABLED the cascade layer (as expected) while 2.0 DISABLES the cascade layer. Reversing the behavior of a toggle from one version to the next creates confusion.

PROPOSED SOLUTION
Cascade layer should be active when the toggle is ON and the label should be changed to “Enable Bricks cascade layer (RECOMMENDED)”

This aligns with standard UX practices for toggle switches and clearly communicates the developer-recommended selection.

8 Likes
2

Yes please! No means no.

1 Like
3

Not the best UX… Completely agree. You don’t enable to disable a feature.

1 Like
4

I completely agree. That’s why I initially thought timmse was wrong in this report, while I was wrong about the cascade layer being active.

2 Likes
5

it’s pretty common across all the Bricks settings… if something is enabled by default (when grey), you toggle to disable it.

SCR-20250720-ogbg
SCR-20250720-ogbg2067×1875 341 KB

SCR-20250720-oggl
SCR-20250720-oggl2018×1148 185 KB

2 Likes
6

Just because it’s common doesn’t mean it’s good practice.

The fact that the clarification in parentheses is needed here reinforces that the current behavior is counter-intuitive.

1 Like
7

Yes, please fix that.

I guess the names and descriptions have been chosen in a way, that no database entry is toggle off and that’s the default for Bricks.

8

I don’t think it is best practice for every toggle label to be written as if the “on/yes” toggle is to enable a feature. I did a quick google scan and found no guidance on constructing the “yes” label for a toggle. I did find references to being clear, short, and concise. The “Disable emojis” toggle shown in wplit’s comment is such an example.

1 Like
9

Consistency is the word you were looking for.

10

I’m a bit confused about what this feature is, since CSS stands for cascading style sheets.

11

the short version is that it lowers the specificity of the default CSS that comes with Bricks so that any custom styling added by people using Bricks will always override.

The main example is people were wanting to add styles to tags…

p {
 margin-bottom: 1em;
}

But were having issues overriding some Bricks default CSS, meaning they’d need to use classes or something with higher specificity to do so.

Most users won’t notice a difference imo.

12

Thanks for the explanation!