Here if we have block level settings we merge with the top level settings to preserve backwards compat but allow extension at a block level.

$result is an instance of WP_Theme_JSON_Gutenberg so I'm passing in the raw data from the current instance and allowing it to be filtered and then creating a new instance of WP_Theme_JSON_Gutenberg. Then I can call merge on it to merge in the data coming from the filter.

The benefit of this approach is that useSetting is much more declarative. If the a setting is add/removed/changed then it's much easier for the Nav Editor to declare support (or not!).

Also it's much harder for developers working on the Nav block to accidentally break the Nav Editor because making a change to a setting is a larger undertaking.

Look ma, no props! 🥳

Nice! It should be possible to delete the whole file and remove the lines where removeNavigationBlockEditUnsupportedFeatures is imported and called.

I worry that if all blocks can add things here:

• we'll get a huge array in the end, these valid bits should be only for general settings/styles IMO
• how will 3rd part blocks use this possibility?
  Can't the block register its own settings?

Thanks for taking a look.

these valid bits should be only for general settings/styles IMO

Anything that isn't "valid" isn't allowed in the Theme JSON config. Therefore if we don't allow blocks to add to this we can't control them via Theme JSON at this level of granularity.

If the consensus is that Theme JSON should only allow for configuration that applies to all blocks, then the feature has limited somewhat reduced utility for the configuration of (more specialised) blocks as it's a fact that many (almost all) block features won't apply generally across the board.

The objectives that this exploration seeks to explore are:

• we should be able to easily and reliably re-configure the Nav block to be simpler for use in the Nav Editor screen in such a way as it will be resilient to change.
• Themers should be able to easily configure the Nav block to support feature X or Y (outside of the context of the Nav Editor).

As a result, I think we should at least consider opening up Theme JSON schema for extension by developers (Core or otherwise).

By doing so we will afford great flexibility and power to block builders to allow Themers (or even users!) to configure their blocks without needing to understanding complex hook/filters.

Key point: if we don't agree that Theme JSON should be extensible, then it would seem that we will need to declare it as not suitable for configuring blocks at a granular level. It will be purely for configuring common things such as spacing, colors...etc, but not for individual features.

The knock on effect for this on the Nav Editor project will be that we must move Theme JSON alongside Block Supports API as defunct for the purposes of configuring the Nav block inside the Nav Editor. This will leave us back where we are today - a plethora of brittle hooks and filters and overrides.

I've had little/limited involvement in the Theme JSON project and so I'd like to ask the opinion of @oandregal (and others) what they think. If this experiment is going against core principles of Theme JSON and Global Styles then please do let us know.

we'll get a huge array in the end

This is also a concern of mine.

how will 3rd part blocks use this possibility

Good question. They can't at the moment. However, we could (in theory) expose APIs to allow blocks to register their own Theme JSON settings.

Can't the block register its own settings?

It can't right now because this is a PoC 😄 But in the future we could enable this.

There is a color array just below, I was wondering if it should be possible to override the color settings using that instead of a new setting?