Explore options to add back semantic classnames to block wrappers

[glendaviesnz]

Description

As noted here, and here the move to random class names for applying layout styling in the likes of the Buttons block has removed the ability of themes/plugins to easily target elements based on layout.

For instance, in WP 5.8 a button block that was centrer aligned would have a class assigned to indicate this:

<div class="wp-block-buttons is-content-justification-center"></div>

but in 5.9, a button block that is center aligned just has a random classname assigned to apply these styles:

<div class="wp-container-620589d3d9565 wp-block-buttons"></div>

Ideally this should be done in a way that does not involve serialising these classnames in the saved block content, so the Style engine seems like the best place to explore adding these back as this can enable it to be done at runtime from the current block semantics in both the editor and frontend.

Additional discussion has taken place here and here, in relation to the value of semantic classnames to allow themes to override styles.

This needs to be balanced out with a desire to not expose too many classnames that may not be intended as a permanent API, but which theme authors may assume they can depend on.

[coreyworrell]

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;
}

[Luehrsen]

Yes, this is a real issue.

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

[gziolo]

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?

[Luehrsen]

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.

[fabiankaegy]

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.

I'd have to agree with that statement. Custom theme development is not jet and may not ever come to the state where we can purely rely on theme.json and therefore relies on these state describing classnames. And that is not just for styling purposes but also in order to gain insight into the state of a component via JS.

I can sympathize with the the issues that are trying to be addressed here. But the move away from state describing classnames would make it very very hard if not impossible to work with the generated markup.

[xwolfde]

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?

I had a similar issue with post-id in a page, where more as one blogroll is display and therfor the same id is used twice - which results in an validation error...

Therfor I would suggest to use random-numbers in the id like this and leave the styling attributes in the class:

<div id="wp-container-620589d3d9565" class="wp-block-buttons is-content-justification-center"></div>

Important note on the randon number in the id: If the same block with the same content might be used more as one time in the same page. take care, that is getting a new number every-time its insertet in the page.

[cbirdsong]

Have CSS custom properties been considered as a solution? They could work with just regular CSS, no convoluted server rendering trickery or messy-looking unique IDs required. The defaults would appear in the global styles block, and elements with custom widths could have them inline.

Example going off the conversation in #38974:

.is-align-content{
   max-width: var(--wp--content-width);
}
.is-align-wide {
   max-width: var(--wp--wide-width);
}
.is-align-full {
   max-width: var(--wp--full-width);
}

<div class="wp-container wp-block-group is-align-full has-custom-layout-width" style="--wp--content-width: 50rem; --wp--wide-width: 80rem;">
   <div class="wp-container wp-block-group is-align-content">
      <!-- stuff -->
   </div>
   <div class="wp-container wp-block-group is-align-full">
      <!-- stuff -->
   </div>
</div>

These class/variable names are just approximations since I’m not super familiar with the FSE/theme.json layout system yet. Relatedly, apologies if I’ve missed something about the architecture that makes this impractical!

---

Fleshed this out further in:

• Tracking: extend layout options in Gutenberg #39336