WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.51k stars 4.2k forks source link

Allow custom style variation classNames #11763

Open greatislander opened 6 years ago

greatislander commented 6 years ago

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 https://github.com/WordPress/gutenberg/pull/7362#issuecomment-398342742). 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 commented 6 years ago

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

vicolaspetru commented 6 years ago

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

mrwweb commented 5 years ago

@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 commented 4 years ago

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

apsolut commented 4 years ago

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

skorasaurus commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

mkkeck commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 10 months ago

+1 want to use tailwind classes

kaelansmith commented 8 months ago

+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.