Twenty Twenty-Four: Many block styles affect all blocks

[wildworks]

Originally reported in Gutenberg repo: ​https://github.com/WordPress/gutenberg/issues/60352

TT4 defines block styles for some blocks and the actual block style CSS is defined via inline_style property. This CSS only contains selectors for block styles, so it affects all blocks. For example, if you copy a block style or enter its CSS class name in the Advanced panel.

The register_block_style() function itself targets a specific block. Furthermore, in TT4, I don't think these styles are expected to be applied to anything other than the target block.

Therefore, I would like to suggest updating the inline style, for example, as shown below.

From:

function twentytwentyfour_block_styles() {
	register_block_style(
		'core/details',
		array(
			'name'         => 'arrow-icon-details',
			'label'        => __( 'Arrow icon', 'twentytwentyfour' ),
			'inline_style' => '
			.is-style-arrow-icon-details {
			}',
		)
	);
	// ...
}

To:

function twentytwentyfour_block_styles() {
	register_block_style(
		'core/details',
		array(
			'name'         => 'arrow-icon-details',
			'label'        => __( 'Arrow icon', 'twentytwentyfour' ),
			'inline_style' => '
			.wp-block-details.is-style-arrow-icon-details {
			}',
		)
	);
	// ...
}

[wildworks]

The Pill style for the Post Terms block also affects links within paragraph blocks

[poena]

Hi

If a user adds a class in the CSS class field in the Advanced panel, that is a deliberate action, and I would expect the style to continue working the same as it has since release.

If the CSS is limited to specific blocks as suggested, there would not only be a change for those that has copied the block style using the built in feature, but also unexpected changes for any site where a user has already manually and deliberately added the class names.

It would have been possible to limit the CSS before the theme was released, but I don't think it can be changed at this time?

---

If we still want to address this, we should check if other bundled themes have the same issue.

[wildworks]

If a user adds a class in the CSS class field in the Advanced panel, that is a deliberate action, and I would expect the style to continue working the same as it has since release.

That is certainly true. However, I suspect that very few users understand the class names generated by block styles and add them explicitly, or use the "Paste Styles" action to apply a particular block style to other blocks as well. Personally, I think this is a bug that should be fixed.

Additionally, if users define their own block style and its slug matches the slug of their theme's block style, a style conflict will occour, even if the targeted blocks are different. Using TT4 as an example, let's say a user adds a style called asterisk to a paragraph block. At the same time, the astarisk style for the Heading block defined by the theme will also be applied to the Paragraph block.

we should check if other bundled themes have the same issue.

Based on my research, this issue may also occur in other themes, albeit to a limited extent. Most of them are selectors called .is-style-outline .wp-block-button__link. For example, if you wrap a Buttons block in a Group block and add a CSS class called is-style-outline to the Group block, the Button inside will have unintended styles applied.

Below is a list of themes that have this style.

• ​Twenty Eleven
• ​Twenty Fourteen:
• ​Twenty Fifteen
• ​Twenty Sixteen
• ​Twenty Seventeen
• ​Twenty Twenty

[poena]

I could not find a discussion specifically about the selectors in the original GitHub repository. But I found that the original design did include paragraphs with asterisks: ​https://github.com/WordPress/twentytwentyfour/issues/45
It was removed because with the original implementation, the asterisks were announced by screen readers. -Not because the style was unwanted for paragraphs. It was later replaced by a CSS only solution, and the asterisks are not announced anymore.

The selector for the custom list item style includes ul.

Yes, the name property in register_block_style() should have been prefixed, that problem is related, but it is too late to change the class name because it would be a breaking change.

Is the problem that users can create their own custom styles with the same class name?
Or as reported on GitHub, that When you "Copy Styles" and "Paste Styles" from one block to another, the custom block style is copied too.

If a user is capable of creating their own custom styles, they are also capable of removing class names from the input field. Developers can also unregister styles they do not want, and replace them.

If a user copies a style and don't like the result, and they don't know how to remove it using the field, they can use the undo step or delete the block and add it again.

If a user has intentionally used the CSS class name, and the CSS selector is updated to work only for a single block, they can't re-add the style without knowing how to code their own.

So the difficulty gap between these scenarios is rather big.

---

In theory, WordPress could force the CSS to only apply to the block that matches the property that is used in register_block_style(). Without requiring the theme developers to manually include the block class names or elements.
In reality, since this was not enforced from the start, it would break backward compatibility.

[wildworks]

Sorry for the late reply.

If including the block class name in the CSS selector is a breaking change, should we close this ticket as "wontfix"? It may not be a problem if there is a way to remove unintended CSS classes without the user having to code them.

However, when defining block styles in a new default theme that will be added in the future, it is better to decide whether to include the block class name in the CSS selector based on the expected specifications.

Related to this ticket, it might be a good idea to discuss whether or not to copy additional CSS classes when copying blocks in the first place. See ​https://github.com/WordPress/gutenberg/issues/60352#issuecomment-2106100503