Style hooks - default named values override custom saved values in editor for server side blocks.

[Addison-Stavlo]

Describe the bug
Semi-related to #24387.

Style hooks seem to be written with the intent to support default styles to be defined on the block- ex:

gutenberg/packages/block-editor/src/hooks/color.js

Lines 70 to 76 in 65258a0

	// allow blocks to specify their own attribute definition with default values if needed.
	if ( ! settings.attributes.backgroundColor ) {
	Object.assign( settings.attributes, {
	backgroundColor: {
	type: 'string',
	},
	} );

However, in practice this seems to not play nice in the editor. With server side blocks, it seems that the class names for the default named styles are still applied (in the editor only) even when custom values are saved. This does not seem to be coming from the server side styles application from the gutenberg_experimental_apply_classnames_and_styles function in blocks.php (which is also the mechanism for delivering these styles for server side blocks on the front-end).

To reproduce

Below I will explore this with a server side block, "Site Title".

1. Add the following to attributes in Site Title's block.json file:

		"textColor": {
			"type": "string",
			"default": "secondary"
		},
		"backgroundColor": {
			"type": "string",
			"default": "primary"
		},
		"fontSize": {
			"type": "string",
			"default": "large"
		}

2. Load the editor and add the site title block to the page. It should have the default values applied as expected:
   
   

3. Edit these to be custom values, save, and reload the editor. Notice that while the block has the visual custom styles applied, the settings in the sidebar pick up the default values instead:
   
   Instead of the saved and visible font size of 56, and the two custom color values for font and background, the sidebar shows the default values instead:
   

4. Inspecting the element reveals that the classnames for these default styles are also applied to the block (in this case they are overridden by the styles applied by the saved custom values):
   
   We would expect that they should not be added since custom values are saved.

Because of these classnames, we may notice that step 3 in other themes may result in the block also visibly having the default styles in the editor instead of the custom saved values. For instance with seedlet blocks (which adds an !important flag to some of the styles that are added by these un-wanted classnames) we see the default values loaded in the editor with the custom values on the front-end.

Editor:

Front-end:

While that last example is theme-specific, these class names should never have been added in this case in the first place.

Expected behavior
The class names of the default styles not to have been added when custom values are saved.

[Addison-Stavlo]

FYI @youknowriad

[youknowriad]

Did you manage to find why the classNames are kept when you select custom values?

I know we have a special mechanism that "keeps" extra classNames in the className attribute if needed but in this case, these classNames shouldn't be considered as extra classNames, I wonder if it's related to that.

[Addison-Stavlo]

Did you manage to find why the classNames are kept when you select custom values?

Im not quite sure. But an important distinction is that the classNames actually go away and work as expected when you select the custom values. The problem happens when the editor is reloaded or revisited afterwards, at that point the classNames are added again and the selections in the style pickers show the defaults instead of the actual values as well. So it seems to be something specific to when the saved block is loaded in the editor? 🤔

[annezazu]

Just an FYI that I did the best I could to label this but if others have a better possible label, please update!