Global Styles: Allow themes to opt out of core theme.json

[scruffian]

The core theme.json (as well as potentially the styles in block.json: #34180) represent some opinions which some themes may not want to inherit. We should build a mechanism in theme.json to disable them.

This is similar to what the wp-block-styles theme support does at the moment. See #37255.

[oandregal]

Just wanted to share #37550 as it touches on this specific thing (absorb the remaining CSS bits so themes can override easily). At some point, we may want to introduce a flag that allows to "reset" all core styles. Though, I wouldn't do that until we absorb the remaining pieces (block styles & block style variations).

[github-actions]

Hi,
This issue has gone 180 days without any activity. This means it is time for a check-in to make sure it is still relevant. If you are still experiencing this issue with the latest versions, you can help the project by responding to confirm the problem and by providing any updated reproduction steps.
Thanks for helping out.

[scruffian]

Still relevant

[oandregal]

Looked at the related conversations, and I'm having trouble understanding what this means.

This is what I understand:

• We are trying to migrate the block styles to the global styles system (via the __experimentalStyles in block.json so far).
• When doing so, we need to build it in a way that respects the wp-block-styles theme support. This is, some block styles are always enqueued and some other (more opinionated) styles won't unless the theme opts-in. We need to make sure to consider this when migrating opinionated styles to the __experimentalStyles approach.

Does that captures the goal?

This leaves me with a few questions:

• if the theme.json of the theme loads after core and blocks styles it can override anything, do we need to do anything else? Do we need perhaps a "reset" theme.json (ala "reset" CSS) for some scenarios?
• how the opt-in works with themes with and without theme.json?

In essence, my past self may have understood what this issue tries to capture, but my current self has some lacunas :) Could you offer some clarifications?

[scruffian]

I think it's much simper than that. WordPress itself contains a base theme.json file which contains some preset colors, settings, styles etc. Themes should have a way to opt out of that entirely and start with a base that is empty.

[oandregal]

We already have a mechanism to "opt-out" or tweak core defaults. It's per datum (setting, style, etc). Perhaps my question can be boiled down to: what are the things themes can't do now by overriding the specific things from the core theme.json?

(I want to understand the needs before we jump into adding more complexity. See related #45171 )

[scruffian]

We have a mechanism for themes to opt out of opinionated styles for blocks, using wp-block-styles. The suggestion here is to build the same affordance for theme.json. It is true that themes can override each of the default settings with their own, but we should also just allow themes to totally opt out of those defaults so they have a clean starting point.

[samikeijonen]

but we should also just allow themes to totally opt out of those defaults so they have a clean starting point.

Yes, exactly this. Because in custom client work Core generated styles are pretty much always in the way and breaks existing styles when updating Core.

[tresorama]

Any news on this ?