Allow custom style variation classNames

[greatislander]

Is your feature request related to a problem? Please describe.

The block styles variations API introduced in #7362 uses an is-style-{styleName} className to the block for style variants. This works well for core blocks and new blocks, but may be overly opinionated for converting existing content that has an established approach to styling variants (see #7362 (comment)). For example, a pattern library that uses BEM conventions might use .element for a default element, and .element.element--variant for a variant of that element. I'd advocate for a solution that does not require changing an existing naming convention if one exists.

Describe the solution you'd like

A className attribute could be added to each style variation which, if supplied, would be used instead of the default generated className. Here's some pseudocode:

styles: [
    { 
        name: 'default', 
        label: __( 'Rounded' ), 
        isDefault: true 
    },
    { 
        name: 'outline', 
        label: __( 'Outline' ),
        className: 'button--outline' 
    },
    { 
        name: 'squared', 
        label: __( 'Squared' ) 
        className: 'button--squared' 
    },
],

Describe alternatives you've considered

The only alternative at present is to use the opinionated is-style-{styleName} naming convention.

[mrwweb]

Completely agree. The point about converting old code seems especially relevant.

[vicolaspetru]

It's possible to get active style?
If I want to change the paragraph position depending on style, how I can do this?

[mrwweb]

@vicolaspetru The CSS class is applied to the block container both in the admin/editor and front-end, so registering gutenberg editor styles should be all you need to do.

[wp-stars-vienna]

Ist der still no way to remove that 'is-style' prefix? i just need that to use bootstrap classes.

[apsolut]

Please add filter to remove/disable prefixes like: has- , is-style-

[skorasaurus]

Admittedly, requiring to use the is-style prefix is frustrating because we're having to change our naming structure (BEM based) for our growing pattern library/components to match Gutenberg's decisions. :/

[ecdani]

As a workaround you can prepend a whitespace to your class. Then you will have a useless "is-style-" class and the class you want.

[jurajk]

@ecdani Tried your solution. Turns out when you change between variations, the classnames are always added, not changed.

in my example i want to create a large and small paragraph. when i change default paragraph to large, .is-style and .text-large get applied. when i change agains to small, text-large remains and text-small gets added. changing to default again keeps those previous classnames and adds is-style-default.

[Takkster]

Still no solution for this? I'd like to use my existing classes so I don't have to manage Block Editor CSS and my Global CSS ...

[ecdani]

You are right @jurajk .
In my case i ended up using the provided classes.
But in other zone of my code i'm using the blocks.getSaveContent.extraProps filter. It allows me to intercept the classes and edit it before save it.
I see it here: https://wordpress.stackexchange.com/questions/308021/add-custom-class-to-core-blocks-in-gutenberg

Maybe it will be useful to someone with this problem ...

[jurajk]

@ecdani thanks for the example. i was hoping to do this outside javascript, but it does the job nicely.
🙌

[mkkeck]

I think, there would not be an option near future.
See #33675.
That's why I have to add for example redudant code into my Bootstrap CSS files or add redudant custom classes to each associate block (like buttons, columns).
It does not make sense to add tons of classnames to blocks, which may be end in unaspected results, but that's the only solution for now. Other solution is adding tons of for example button styles matching the used CSS framework, filter out the 'is-style-' on render callback.
And of course: 'has-background-nameofcolor' would be much better than 'has-nameofcolor-background-color', but the team of Gutenberg had another opinion.

[tomhartill]

I had to just use a string.replace function in the save function. This really needs to be a feature, as well as allowing custom classnames per block. The classname conventions are far too verbose for my liking, I understand why they exist, but us back end devs are not idiots and understand the reasoning, we should be allowed to make our own classes without having to jump through hoops or use hacks, it would make developing these blocks much less painless

[kurtrank]

I agree we should have a way of opting out of these standard class names. Providing an optional className as in the original post is a great solution that wouldn't lock you into any naming convention.

I am in the same boat where we have a theme built around a design system that uses BEM naming convention, and I hate the fact that we cannot use the built-in block styles feature. It seems like a great user experience with a lot of work put into it but the class format it generates means I haven't been able to use it for any blocks. I have explored hacks to try to get it to work and even looked into building a custom style previewer but in the end I use a basic select control for blocks that really need a way to pick a variation.

I feel this ties in to #41349. Having a predefined class name format might be nice when you are mixing and matching themes and blocks on a little personal site, but organizations building cohesive projects with their own blocks/themes should be able to say "we don't need our custom blocks to follow that predefined naming convention".

We can see some steps toward this, like theme.json using the __experimentalSelector option referenced from block.json. This allows for styling to be applied even if you do not follow the .wp-block-{name} convention.

[chrillep]

+1 want to use tailwind classes

[kaelansmith]

+1 also want to use Tailwind classes (on headless projects); currently I strip the class prefixes with JS on my decoupled front-end, which is an ugly hack.