Another instance this happens is for link colors.

<p class="has-text-color has-primary-color has-link-color">
  This contains a <a href="#">link</a>
</p>

A class could be applied of which color was selected. Then you could do something like:

.has-primary-color.has-primary-link-color a,
.has-danger-color.has-danger-link-color a {
  text-decoration: underline;
}

Yes, this is a real issue.

I've written about this in a more abstract way in issue #38694.

The work on the Style Engine has started recently. I think it would be great to include this use case in the roadmap so we could come up with a good solution. I commented about this issue in #38167 (comment):

It looks like the automatically generated class names to move granular class names and styles outside of the block's HTML to the style tag introduce some challenges. See #38719 and #38694. It would be great to keep that on the radar while working on the Style Engine implementation.

There are vast benefits of the single automatically generated class name for a given block:

• no excessive pollution of the HTML for the block that simplifies validation and deprecation handling
• the ability to target inner HTML tags through CSS syntax generated on the server with style tag instead of complex handling through __experimentalSkipSerialization flag in block support.

However, it would be great to keep the flexibility of the current blocks that use several discrete class names to indicate selected block customizations like colors, fonts, etc.

Do you have some ideas on how the same goal could be achieved if you were able to access the state with all applied style modifications to the block? Would it be possible to leverage WordPress hooks in any way?

Do you have some ideas on how the same goal could be achieved if you were able to access the state with all applied style modifications to the block? Would it be possible to leverage WordPress hooks in any way?

Having access styles though hooks/filters would be great, but it still does not solve the underlying problem: The loss of syntax that describe the intrinsic state of the frontend component the user wants it to have. So if having access to the styles means losing the class names, that would be a hard no from us.

The practical reasons behind that are quite straightforward: You cannot target explicit styles hidden behind a selector with a random name. In a lot of larger systems you need these styles to bridge the gap between systems and to give external systems the ability to understand the state the block/component wants to be in.

The most basic example of 'external systems' would be an external stylesheet. But the possibilities are limitless. From JavaScript applications that act upon having certain classes present in the DOM, towards complex DOM tree manipulation with workers in Cloudflare.

To be perfectly clear here: Removing explicit classnames that describe state in favor of implicit, random classnames that describe style would effectively make any Gutenberg frontend a walled garden, which is the antithesis to openness. At least from our point of view this has to be avoided at all costs.