Continuation of Block Style Variations

[mtias]

Once #7362 lands, we'll have the ability to register new block variations (based on classes) with automated previews. With this foundation there are further ideas of how this functionality could be extended.

Register New Styles

Themes / Plugins should be able to easily register new variations from the client or server.

Unregister Existing Styles

Themes / Plugins should be able to unregister existing block style variations for a specific block. (A plugin may also want to disable style variations entirely across all blocks.)

Change the Default

A Plugin / Theme might want to make a specific variation the default one for that block type.

User Defaults

A user might want to make a specific variation the default whenever they insert a new block of the type.

• Allow setting a default variation for the user (locally stored?).

Custom User Styles

A user might be able to write a custom class (in the "Advanced" block tab) and register it as a block variation.

Concept:

Package Customizations as Classes

A user should be able to modify the aspect of a block (padding, font-size, etc) and save this not as inline styles but as a specific class to be reused. These don't necessarily have to become "style variations" but should be selectable in the advanced -> class input.

Show Style Variations in Class Selector

Style variations should also probably be exposed in the class selector.

[ZebulanStanphill]

A user might be able to write a custom class (in the "Advanced" block tab) and register it as a block variation.

Concept:

This reminds me a lot of the classes feature in Oxygen Builder:
https://oxygenbuilder.com/documentation/styling-options/classes/

I think this is a great idea! 👍

Side note: I recommend checking out Oxygen Builder. I found out about it recently and was very impressed. It does pretty much everything, with the only downside being that its proprietary software. Interestingly, it uses a builder system that is actually a bit similar to Gutenberg in that it is more "block"-based, and it has no strict section→row→column→module system like nearly every other page builder; you can have columns, but it allows you to build stuff using a CSS flex-based system which works really well and is a lot cleaner than the deep levels of nested <div>s you get with other builders.

[felixarntz]

Themes / Plugins should be able to easily register new variations from the client or server.
[...]
Themes / Plugins should be able to unregister existing block style variations for a specific block. (A plugin may also want to disable style variations entirely across all blocks.)

Those two parts are the steps I consider the most crucial for now out of the list. Many themes provide elements in different variations, there may be different separators, quotes, or especially buttons, where you often have a distinction between a regular (secondary) button and a primary button, just like WordPress itself has in the admin. Having this map to Gutenberg in a simple way by registering a block style is an easy-to-implement solution for the theme developer.

In terms of implementation, I can see it either being handled via theme support (as in add_theme_support( 'block-styles', ... ) and add_theme_support( 'disabled-block-styles', ... ), or via extra functions made available via Gutenberg (as in register_block_styles() and unregister_block_styles()). I think the first is most in line how we would commonly handle it, and I like to reuse the concept of theme support - especially if we only allow adding new styles, but not disabling existing ones, I think we should go that route. On the other hand, this is (or might evolve into) something more specific than just a simple on/off feature or a list of things, so I also see an advantage for introducing specific functions for that purpose.

This was previously discussed in #5360 (comment) (theme support) and #5360 (comment) (extra functions), some input around that to consider as well.

[boemedia]

I just installed 3.2.0. Is it correct that the block styles/settings have been taken out of the block itself? What's the main reason for it? From a design/accessibility perspective, this is an odd choice. For instance, for people with tunnel vision, the proximity of related actions is very important. Now when you select a block at the bottom of your screen, you won't see what happens at the top left.

[mtias]

What do you mean with out of the block itself?

[chrisvanpatten]

@boemedia Might you have the "Fix toolbar to Top" option active by mistake? Make sure it's not checked here:

If that's checked, it would show the toolbar at the top of the screen, away from the block, as you described:

If un-checked, the block controls should still be visible with the block itself:

[boemedia]

Thanks, @chrisvanpatten , I must be blondish... Totally forgot about that option being there. I must have been playing around with it with a previous update.

[pascalknecht]

@mtias I just checked the block variation implementation. I think it is great but I think it should not force the user to use a special kind of class system. Many people use BEM or other CSS styling methods to keep the CSS clean. The current implementation forces the user to use the class .is-style- which for me is too opiniated. Could we explore another way there?

[0aveRyan]

To @pascalknecht's point, CSS classes aren't always used as style selectors. Common to target classes in JS for functionality -- .is-style-init-vid-autoplay or .is-style-disable-vid-ads would be confusing and verbose.

[galloppinggryphon]

Supporting what @pascalknecht said, I think the current system is too opinionated, and doesn't play nice with existing CSS frameworks, e.g. Bootstrap or UIKit. These already have customized button styles and whatnot that you just can't use with the block editor as it is (please let me know if I'm wrong!) without, e.g. rolling your own buttons.

What about being able to directly register custom class names for each style?

wp.blocks.registerBlockStyle( 'core/quote', {
    name: 'fancy-quote',
    label: 'Fancy Quote'
    classNames: 'pull-quote fancy-quote'
} );

[jorgefilipecosta]

Hi @mtias,
Regarding the feature "Custom User Styles", when the user (e.g: an admin) sets a new class as a style, should this block style be available to all users site-wide, or should this be an user-specific setting?

[chrisvanpatten]

The user (e.g: an admin) sets a new class as a style, should this block style be available to all users site-wide, or should this be an user-specific setting?

I really like the idea of defaulting to globally-registered styles — it would allow a site creator to easily set up some "pre-sets" that their content creators can leverage later on.

[mtias]

@jorgefilipecosta site wide, depending on permissions.

[klihelp]

+1

[youknowriad]

A lot of improvements have been achieved for the block style variations. What's remaining here? Should we close this one?

[mtias]

I don't know if allowing a custom class name has been added, but it'd make sense to support it, even if discouraged, for multiple reasons.

[skorasaurus]

I don't know if allowing a custom class name has been added, but it'd make sense to support it, even if discouraged, for multiple reasons.

It has not, there's an issue for it - #11763

[coreyworrell]

Transferring #31360 to here as advised.

What problem does this address?

Makes adding custom classes more user friendly for styling options that may not fit into the other options offered by Gutenberg already.

What is your proposed solution?

Allow user to select from available classes that the theme offers along with adding custom. Similar to how EditorsKit plugin does it by using a token field.

Having the theme provide (via JSON and/or PHP) a list of classes (with labels) and possibly by group could make this very easy.

Utility classes for padding, margin, maximum widths, etc could take advantage of this. A label could be used with the underlying value being the class itself.

[mikachan]

This is another issue that probably needs to be transferred to here: #42297