Registered block styles set to be the default aren't actually set as the default

[skorasaurus]

Description

You can set what block style is applied (or already selected) when opening a block for first time in the editor.

New Default block styles can be set through register_block_style when is_default parameter set to true;

When registering a block style and setting it to default, the registered block style (blue quote in the example) is not set as the default; the default style included in Gutenberg is still selected.

Step-by-step reproduction instructions

1. Include this code snippet in your active theme's functions.php

if ( function_exists( 'register_block_style' ) ) {
    register_block_style(
        'core/quote',
        array(
            'name'         => 'blue-quote',
            'label'        => __( 'Blue Quote', 'textdomain' ),
            'is_default'   => true,
            'inline_style' => '.wp-block-quote.is-style-blue-quote { color: blue; }',
        )
    );
}

2. create a new page/post
3. add block containing the block style.

Screenshots, screen recording, code snippet

screen recording shows what I describe.
https://user-images.githubusercontent.com/955351/154548693-caf94e52-d847-4f4a-95de-5b424b499edb.mp4

Environment info

• wordpress 5.9;
• gutenberg 12.6; twentynineteen theme.

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[talldan]

It looks like you end up with two defaults in the store if you do this (the original default and the new one).

Possibly the previous default should be set to isDefault: false.

Even if that's fixed, I don't know how well it would work as the block editor treats the absence of a class name as the default 🤔

Coupled with #20706, the way defaults work is a bit of a mess.

[AlkoKod]

Same when registered with javascript.

[mediaformat]

Not sure if this is the exact same issue, or a related UI bug.

If a style has isDefault set to true, the button's label gets replaced by Default

"styles": [
  { "name": "dark", "label": "Dark" },
  { "name": "light", "label": "Light", "isDefault": true }
],

EDIT: re-reading the OP, this is a different issue.

[Bexy-Lyn]

But the slug should remain as specified, right? Since I currently have the problem that the new default blockstyle not only has the name "Default" (doesn't bother me that much), but also doesn't get the class name assigned. Therefore my styles do not work :/

EDIT: I noticed, that the default behaviour of the "Default" style causes my issue. If I add another style and switch to the other style and than back to my default style, the class is applied. Just like the "is-style-default" class works. I guess I will have to find a way to workaround this behaviour. I wished Gutenberg would handle this differently though, as this makes no sense to me. If I add a blockstyle as default, I also want to add the blockstyle's class by default, wouldn't I?

[BVBAccelm]

Any movement on this issue? I'm experiencing the same problem; I cannot set the default style on the image block to be one that I added to make them responsive. It's a concern that content entry people will not remember they have to do this each time, and we'll end up having to re-visit most pages to apply these styles after the fact.

[talldan]

There's no update at the moment. It's unfortunately not easy to solve, it may even be impossible. I think the feature is conceptually flawed. My suggestion would be to not use isDefault, and it may have been better if that feature hadn't existed from the start.

To breakdown the problems:

• The block editor typically considers a block having no block style variation set (and no is-style-x classname) as the default. Considering a block that has is-style-default or another default classname applied as the default doesn't really make any sense in terms of how CSS works. For CSS you generally add classnames to extend/override styles. I've never seen a style system that adds a classname to something to implement a default.
• When extra block style variations are registered that have is-style-default, there are then multiple 'default' styles variations registered. If a situation arises where multiple plugins add default styles to a block, which one is actually the default? It seems impossible to say.

Those things actually feel insurmountable to me, and I think it may be better to deprecate the ability to set isDefault and remove it from the docs.

[ndiego]

Those things actually feel insurmountable to me, and I think it may be better to deprecate the ability to set isDefault and remove it from the docs.

After experimenting with this today, I concur. isDefault is fundamentally flawed and I think we should deprecate this in 6.7. It doesn't actually work, and it's not clear to me if it ever really did.

cc @aaronrobertshaw as this is tangentially related to the discussion we had during the section styles Hallway Hangout.

[aaronrobertshaw]

Thanks for the ping! 👍

My initial thoughts are that a couple of concepts around a "default" block style were conflated and conflict with each other resulting in the broken experience we have now.

The primary use of the "default" block style seems to be as a mechanism to simply deselect other block styles, essentially a way to get back to the default styles defined for a block type.

The secondary use, leveraging isDefault, is more geared towards defining the actual default styles for a block type. Without full context and history here, I think this is where the feature might have gone off the rails.

These default styles should be defined for the block type itself so if there isn't any other block style selection, these are the styles that are applied, i.e. an actual default. If the styles aren't intended to be a true default, then the block style shouldn't really be flagged as isDefault.

In other words, default styles for a block type should be just that. Block styles seem like the wrong tool for the job here.

Themes leveraging theme.json can define block type styles easily. That style data is also filterable allowing plugins to inject default styles for blocks they may be registrering. Then there's always enqueuing a block specific stylesheet.

Given all that, I wouldn't be opposed to deprecating isDefault. It feels broken, unfit for purpose, and generates lots of confusion.

---

As a side note, a possibility floated in the Hallway Hangout Nick mentioned, was that the theme.json partials that block style variations now support could be used to define "default" block styles for block types as an alternative to requiring them within the monolithic theme.json file.

In a scenario like this, the partial would provide the devx like defining a default block style but under the hood Gutenberg would assign these styles to the block type within theme.json.

I support the deprecation of isDefault.
When there are multiple style variations, setting "default" should not require the addition of the "is-style-default" class. This is because the absence of a class implies the default style. How is this being considered?

[aaronrobertshaw]

This is because the absence of a class implies the default style. How is this being considered?

This point makes up a large part of my comment above.

I would suggest that default styles are defined for the block type itself. These would then apply until a non-default block style is selected.

Two possible means of doing this are:

• Theme.json block type styles
• Adding styles and stylesheets for registered block types