Specify rules for when certain styles need to be available

Another approach could be to be able to configure the visibility rules on the entity type itself, that would be a more sitebuilder centric approach

Hi Steven,

Interesting proposal. Is it possible to think about rules related to the design systems business domains and not Drupal API domain ?

I have the feeling it would be a mistake to add Drupal related to stuff to styles definitions like entity types (config or content) or plugins types:

background:
  label: Background color
  rules:
     entities:
       - view
       - flag
     plugins:
       - field_formatter
       - block
  options:
    fr-background-action-high--red-marianne: Action-high red Marianne
    fr-background-alt--blue-france: Alt Blue France
    fr-background-alt--grey: Alt gray

Because it is introducing reverse dependency and the front developer is not a agnostic provider anymore.

We can introduce rules related to design and frotn dev. For example, we can add a "levels" or "target" property as defined in the HTML5 specification:

• flow: https://html.spec.whatwg.org/multipage/dom.html#flow-content-2
• section: https://html.spec.whatwg.org/multipage/dom.html#sectioning-content
• phrasing: https://html.spec.whatwg.org/multipage/dom.html#phrasing-content
• embedded: https://html.spec.whatwg.org/multipage/dom.html#embedded-content-2
• interactive: https://html.spec.whatwg.org/multipage/dom.html#interactive-content

Example:

background:
  label: Background color
  target:
    - flow
    - phrasing
  options:
    fr-background-action-high--red-marianne: Action-high red Marianne
    fr-background-alt--blue-france: Alt Blue France
    fr-background-alt--grey: Alt gray

And then, it would be possible for UI Styles consumers (Blocks, Layouts, CKeditor5, Views pager, Views rows, Paragraphs...) to only display the styles related to one target.

This HTML5 content levels list is only an example of "rule", maybe there is a better one. However, it is an example of something not coming from Drupal API.

Is it compatible with your request?

I can follow the approach you suggest.
If i look at it purely from the design system domain i can see some rules that a design system wants to decide upon.

• Only one primary button per page
• A specific font can only be used on a red background
• ...

I'm not sure someone would want to enforce rules like that though.

My question started from looking at it from the backend interface perspective.

We build webplatforms that will mostly be used by non technical webmasters. Therefor we always strive to keep all configuration for webmasters / content editors as minimal as possible.
Using ui styles for heading styling will add a heading style dropdown on every block entity, in 3 fieldset (block styles, block title styles, and block content styles) which would be to much configuration options for our webmasters.

The design system / frontend dev can build a list of utility styles. Maybe even combined with guides on how or when to use them.

Based on that an interface designer can design the drupal backend pages to be user friendly for webmasters and content editors, and decide on what styles should be available for specific purposes.

E.g.
the heading style can be used from CKEditor, and only on block titles.
The background-color style can only be used on block content styles.
The button style should never be used through the interface, as it would always need to use a ui pattern.

I would love to have a way for a developer to control what style should be applicable for each use case.

That doesn't need to be in the yaml file for me.
Layout options however did take a similar approach for this using the Layout Options Section (Rules) → in their yaml files.
It would make sense for all of the modules in ui suite to have a similar way of defining things.

I just stumpled over this and already have a working solution (as a starting point).
Gimme a moment to put this into an MR ....