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:
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.
The “discouraged” note adds further confusion: Is it discouraged to activate the toggle or discouraged to deactivate it?
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.
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.
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.