Try Core's Style API proposal

Problem/Motivation

We are ready to add a new API in Core: ✨ Add a style utility API Active

After SDC in Drupal 10.1 (July 2023), and the Icon API in Drupal 11.1 (Dec 2025), and the upcoming ✨ Add a CSS variables API Active , it will be part of the implementation of design systems APIs in Core, in order to be able to build business agnostic, shareable, Drupal themes, providing design implementations which can be leveraged by display building tools like Layout Builder.

So, we believe this API will be interesting for Layout Builder Styles and here is a prototype of how to use it.

Proposed resolution

We keep the 2 config entity types:

• LayoutBuilderStyleGroup which are similar to Core's Style plugins
• LayoutBuilderStyle which are similar to specific options in the Style plugins

We change LayoutBuilderStyleGroup to allow to "link" a group to a style plugin.

We change LayoutBuilderStyle to allow to "link" a style to a style plugin's option. When there is such a link:

• style's classes are read-only because they are always identical the value of the style plugin's option
• style's group is read-only because it is always the group with is "linked" to the style plugin

We add an "Import" entity form to create LayoutBuilderStyle (and LayoutBuilderStyleGroup if necessary directly from Style plugins)

Remaining tasks

Out of scope of this prototype::

• use of Drupal\Component\Plugin\LazyPluginCollection instead of just storing a string
• config dependency management
• limit to only styles based on HTML classes
• allow multiple styles/groups from same option/style?
• use #styles or Attributes::addStyle() in the preprocesses

Alternative proposal

This prototype is adding the Core API as an upstream of Layout Builder Style: we create LayoutBuilderStyleGroup and LayoutBuilderStyle from the plugins and we rely on the Layout Builder Style to process the styles.

Another way would be to do the opposite: Derive style plugins from the LayoutBuilderStyleGroup and LayoutBuilderStyle config entities and rely on Core's API to process the styles.

User interface changes

Yes, an additional page and some additional information in entity forms and entity lists.

API changes

Only additions. Doesn't change the behaviour of existing APIs.

Data model changes

Each config entity has a new exportable property.