theme.json: whether or not to allow targetting settings that are specific to the block

[oandregal]

Many people have expressed that it'd be convenient to allow themes to configure settings that are block-specific via theme.json. While block attributes & supports are configurable via the existing block filters, theme.json settings have proven very ergonomic for themes, hence the appetite to have more of it.

We've discussed or touched this topic across different PRs & issues, and I figured it'd be good to have a single place to share and discuss.

[oandregal]

I understand how this is appealing and why themes would want to use theme.json to configure any setting the block supports, it's a lot more ergonomic than existing options.

The major drawback I see is that we lose the ability for blocks to inherit global settings

• Right now, if a block declares support for the link color, the block will automatically inherit the theme preference for links (whether or not to support them). No matter the block comes from WordPress core, Gutenberg, or it's a third-party block, we've created a mechanism that everyone understands: if the theme says "no links" links won't be shown across blocks that support them.

• As soon as we allow settings that are individual to the block, themes have to play catch-up to control these settings. Additionally, opening up the settings in theme.json to anything diminishes the value of the block supports API: this is important because it represents a coherent way for blocks to show up UI options to the users, and we use this to generate the global styles sidebar.

Anyway, if the appetite for having something like this is very strong, I feel the first step is to look at how blocks, whether they come from core or any third-party, can declare what attributes/supports/settings they want to expose via theme.json.

[oandregal]

For awareness, @jorgefilipecosta @youknowriad @mtias @getdave @talldan @draganescu

[mkaz]

As soon as we allow settings that are individual to the block, themes have to play catch-up to control these settings.

I think one requirement should be that all blocks must require a default and assume no setting from theme.json. This way themes wouldn't be required to do anything unless they want to override the defaults.

I can see this useful for my code-syntax-block. It has a setting for specifying a color scheme and/or stylesheet to use for the code colors. It would be nice to allow for something like:

{    
    "settings": {
        "mkaz/code-syntax-block": {
            "colorScheme": "a11y-dark"
        }
    }
}

[skorasaurus]

Also discussed at #34908

[carolinan]

I have heard from many theme developers that have been confused about why theme.json does not add support for the editor control, when the setting is enabled.
I think that full control using the theme.json file is expected by many.
It would also lower the entry barrier for anyone who is not already familiar with the block supports API.

[getdave]

I've been thinking about this a fair bit and have even done a very basic exploration in #34784.

From the perspective of the Nav block, some Themes may not want to allow for complex navigations to be created as they have not added support for this or their Theme isn't well suited. In which case, you'd need a way to enable/disable various features of the block (or, depending on how the block is coded, one blanket "switch") without having to jump through several hoops (filters, hooks...etc).

Theme JSON seems like a logical choice for this - a declarative API.

I agree with what @mkaz suggests. When the block exposes settings that should be configurable via Theme JSON they should also have to declare a default. Therefore, Themes won't need to play catch up as they will receive the default and would only need to update their theme.json if they want to modify that default.

If this API came into being, we could encourage block developers to supply the existing default for any setting they expose to avoid backward compatibility issues.

[oandregal]

I've been thinking about this a fair bit and have even done a very basic exploration in #34784.

That experiment was great to consolidate some of my thoughts about this. Thanks for pushing it.

One of the points I've brought up in that exploration (see) was that we'd need to start by thinking how any block (core or third-party) can register custom settings.

The other thought I shared was that it'd be beneficial to think how many of those custom settings can be thought of as block supports, actually:

• In (this thread) we mentioned color and justification.
• In a conversation with @tellthemachines she brought up other cases such as the ability to restrict its allowed blocks: I see this as something that is used by many blocks and so could potentially be interesting to have in theme.json. Not sure how this plays with other mechanisms we have (templates, etc), but from the perspective of being useful to many blocks, it could be worth exploring.
• Also "open on click" (configures if the nav dropdowns open on hover or on click): this is a bit more specific, but perhaps we can think of it as something any other block can benefit from? For example, we have the dropCap setting that only affects the paragraph block at the moment, however, any block can potentially use it because the meaning is clear. Can perhaps openOn/revealOn be a setting with hover and click as values that can be used by blocks with that interactivity need (for example, a <details> block)?

[oandregal]

@carolinan would you mind sharing specific examples when you find them? That'd be very helpful to weigh on this and understand what's the best fit.

[getdave]

Also "open on click" (configures if the nav dropdowns open on hover or on click): this is a bit more specific, but perhaps we can think of it as something any other block can benefit from?

I do agree we should look ti normalise settings where possible. I wonder however, if this will sometimesl catch us out. We're trying to force things like onClick / onOpen to become generic when in fact they are likely to be highly specialised to each block.

Many blocks at the moment control their configuration via attributes. Perhaps there is some interplay between Theme JSON and attributes we could explore?

[scruffian]

The "Social Icons" block is a good example - the settings for the block relate to how it displays so you would expect them to be settable by theme.json, but currently that's not possible.

[warudin]

Since examples are needed, I’m just adding my question to @carolinan on Twitter here:

“Is it the objective to be able to configure every option in core blocks through theme.json?
It would be so helpful to be able to preconfigure things like text alignment, vertical alignment, block alignment, block width, media position, and so on..”

discussion: https://twitter.com/dqipijnenburg/status/1450905514980921350?s=21

[oandregal]

A few years have passed since this one has been created. I don't think it is actionable or reflects the reality and needs of the project right now, so I'm closing.