I feel we have a conflict of concepts in the project at the moment. I am not sure in which direction we are going (in terms of this specific concept) and I think a clear definition of what we want to achieve would be beneficial in understanding the rest of the components and set clear(er) expectations.

Definitions

Before we talk about the conflict of concepts themselves I want to quickly describe (my understanding of) the meaning of the concepts in conflict.

Describing State: Following this concept we want to describe the current state a component, or block, is currently in. A state would describe if an element has a background with the has-background class, or which font size it has with has-font-size-regular. We use these states all over the project and we can easily spot those descriptor-classes with the has- or is- prefixes.

Declaring Style: Sometimes we add some specific style declarations to elements to reflect a state. One example would be the width of columns in the core/columns block. If we set a column to 12% width, a flex-basis: 12% style declaration is added explicitly, as a general description of state (e.g. with has-width-12percent) would lead to a lot of redundancy and duplication. (I'm looking at you, Tailwind!)

Why this matters

As theme developers we sometimes like or need some leeway in terms of how to interpret a certain state of a block or element. For example has-font-size-regular imposes no opinionated value of what regular means. We have some default settings set by the block editor, but as a theme we are free to interpret what regular means and overwrite the defaults.

On the other hand, setting a width on a column declares a very strict flex-basis: 12%, which locks us as theme developers in a corner. We have to use flex for columns, even it we wanted to use something else (like css grid).

My proposal

For us as themers interpreting a state gives us a lot more freedoms to interpret the assumptions compared to working with declared styles. So I would love the project to explore where a style declaration could also be a state description.

One important aspect of modern CSS is the fact, that we do not only have classes to describe state, but also CSS variables. So for example setting --wp--has--width: 12% on a core/column block would still allow the project to have explicitly set defaults, but at the same time allow themers some more freedoms of choice with how we interpret the state.

The ticket #38677 is another example of where a descriptive state would be helpful and a declarative style is applied.

So I would love to add "Describing state over declaring style" to the set of values for this project. I think it has value to encourage contributors to use state instate of styles when refactoring or newly implementing (frontend) elements.

Thank you!