Global Styles: Add support for default styles

[scruffian]

From #27579:

It feels like having a way to set the default padding in the block's supports field instead would make it more convenient for customization purposes. In addition to true it could support an object with default values or anything that the theme.json is using.

As noted on that PR, setting default styles in the way the handbook recommends results in validation errors in the block.

As can be seen in #27582, if we set these values in CSS rather than in the JSON then when the user resets the setting, the CSS takes control, which is confusing for the user.

I agree with @gziolo that we should be able to set this in the block.json somehow.

cc @nosolosw @jorgefilipecosta

[jorgefilipecosta]

I agree that it makes sense to allow blocks to use the theme.json system to apply styles to themselves.
It could be as simple as having a style property in block.json that allows blocks to use anything from theme.json to style themselves.
This system would make sense per selector the block defines so for example the heading block would be able to apply styles per heading level.
The global styles system would then have an additional element on the hierarchy the block styles e.g: it would be core < block < theme < user instead of core < theme < user.

But regarding showing what is the default at the block level e.g: the padding is 1em, even if we specify styles using block.json it is something very complex. The default can be from the theme or from the user or some pattern and when we have semantic nesting on theme.json, the same verse block may have a padding of 1em, when on single post view and 0.5em when rendered on the post list so what default would we show for padding at the block level?
Currently, styles at the block inspector show a value only if there is one explicitly set as an inline value for that block instance and don't show anything when the default is being used. Reset just removes user customization from that instance and uses the "default" (that may come from multiple places and even change depending on the context).
I guess we should explore trying to show some defaults to the user in the editor, so the user knows that there is a default. But probably after we have a semantic nesting ready because that part is what makes the problem challenging. Regarding the reset, I think even if we show the default somehow, a user pressing reset would not remove a value or remove the default it would just remove the user value and revert things to the default.

[mtias]

@scruffian do we have something actionable here or is it mostly covered?

[scruffian]

I believe the way forward here is outlined in #34180

[jordesign]

Looking at #34180 it seems this may now be resolved.

@scruffian can you confirm whether this issue can be closed or not?