CP CSS and CP badges for standard styles

[jacksleight]

As discussed on Discord.

[aerni]

I think it would make sense to have all default configs stored in one place. This includes cp_css, cp_badge, and the default_classes. The config could look something like this:

'default_styles' => [

    'heading' => [
        1 => [
            'class' => '...',
            'cp_css' => '...',
            'cp_badge' => true,
        ],
        2 => [
            ....
        ],
    ],

]

The class is what default_classes currently is. The class config can be a string if you only have one set of classes (like in the example above) or an array if you have multiple styles:

'default_styles' => [

    'heading' => [
        1 => [
            'class' => [
                'standard' => '...',
                'accordion' => '...',
            ],
            'cp_css' => '...',
            'cp_badge' => true,
        ],
    ],

]

All three config options, class, cp_css, and cp_badge should be optional, so you don't have to define them if you don't want to customize anything:

'default_styles' => [

    'heading' => [
        1 => [
            'cp_badge' => true,
        ],
    ],

]

Maybe we can also use the same syntax for the default_styles as we are using for styles. Simply to make it easier for the user. Obviously, each type can only be configured once:

'default_styles' => [

    'this_key_really_can_be_anything' => [
        'type' => 'heading',
        'level' => 1,
        'name' => 'A custom heading name',
        'ident' => 'F',
        'icon' => null,
        'class' => 'text-lg lg:text-xl xl:text-2xl font-bold mt-12 -mb-6 lg:mt-16 first:mt-0 last:mb-0',
        'cp_css' => 'font-size: 1.25rem',
        'cp_badge' => true,
    ],

],

[jacksleight]

I really like the idea of a single array for all the default stuff. I’m unsure about organising the class options like that though, feel like it’d be more convenient to have all the “accordion” related classes in one place?

Another way to structure it could be by expanding the current format, something like:

'default_classes' => [

    'standard' => [
        'heading1' => '…', // simple format when you just need a class
        'paragraph' => [ // expanded format when you need a class and cp_ stuff
            'class' => '…',
            'cp_css' => '…',
            'cp_badge' => true,
        ],
    ],

    'accordion' => [
        'heading1' => '…',
        'paragraph' => '…',
    ],

],

Side note: this is kind of unrelated really but I’m also considering flattening the heading types into something like heading1, heading2 etc. It would simplify the config and also align better with the HTML equivalents.

[aerni]

I prefer your array structure. However, this would imply that you can add different cp_css and cp_badge for each configuration like standard and accordion in this example. I structured the config array the way I did because of your comment on Discord:

I don’t know that it would be possible to implement different cp styles per bard field though. Not without some really nasty hacks anyway.

Also, the main array key should probably be changed from default_classes to default_styles. Or maybe even simply defaults.

[jacksleight]

However, this would imply that you can add different cp_css and cp_badge for each configuration like standard and accordion in this example. I structured the config array the way I did because of your comment on Discord:

Yep, absolutely right, I did say that, and I think the same thing about this structure 😄 . However even if the additional sets didn't allow the cp_ stuff, this would keep open the possibility of adding that later. Or, I have had a play and I don't actually think it would be as tricky as I first thought. It would certainly be nice to able to support those for other class sets. Maybe.

Also, the main array key should probably be changed from default_classes to default_styles. Or maybe even simply defaults.

Yeah, I agree with you on that as well. It would be very easy to rename it and still support old configs, so I'll probably do that.

[aerni]

Sounds good. Oh, and I like flattening the headings btw. I'd add an underscore though: heading_1.

[jacksleight]

I have started working on this and do plan to implement it, however at the moment it requires some really hacky code that I’m not happy with. I’ve submitted a PR to core that tweaks the way the Bard styling works, and would make implementing this far cleaner and more robust, so I’m going to see where that goes before deciding how to proceed with this.

[jacksleight]

Released in v3.1, check the updated docs.