Blocks: Proposal: Box-layout attribute

[scruffian]

Is your feature request related to a problem? Please describe.
Themes need to treat "text" blocks differently to other kinds of blocks which can result in very verbose CSS. It would be useful if we could make a distinction between "text" blocks and other kinds of blocks so that this could be a bit more future proof.

Describe the solution you'd like
One idea I had was a setting in the block definition which could be used in the render to add a wp-block-text class to the output, but I'm open to other suggestion.

Describe alternatives you've considered

[mtias]

Can we trace back why themes need to treat these differently? I believe has-background changes came from the decision to add padding / margin within content when a background color is present. An example being the extra padding added on paragraphs when a bg color is set. This behaviour is not ideal since it assumes a little too much. With dimensions being something we can declaratively incorporate into blocks (sometimes exposing a padding control) this is something that could migrate into theme.json spec instead.

[scruffian]

That's one instance but it's not the only one. For instance a full width image block should go right to the edge of the screen, but a full width text based block should now.

[mtias]

I mean, the box should probably still go to the edge, just with some padding. But it should be possible to not have the padding if the design demands it.

[scruffian]

Right, it would just be nice to be able to write in the theme:
.alignwide.is-text-based { padding: 0 1em }

rather than having to target each block separately, which won't work if new/custom blocks are added.

[mtias]

I also don't think that's the text nature that matters there. It's more of a box-layout behaviour — an icon block might also want that extra space, for example, even if it's not text based.

[scruffian]

Yeah that's true. Do you think that having a way to define that for each block would be useful?

[mtias]

Probably, yes, but we need to find the right semantics to express it without excessively increasing complexity

[scruffian]

None of the options in block configuration seem to be able to do something like this - perhaps the closest would be to add a new option to supports? Otherwise we could add another top level definition to the options we pass to block registration but that seems like overkill.

[jorgefilipecosta]

If the idea is to allow one to select apply rules to all text blocks, we have text block category, would it make sense to be able to use the block category on theme.json selectors? Meaning the selector would be compiled the selectors of each individual block using the or CSS ",". cc: @nosolosw

[scruffian]

As @mtias pointed out, it's not just text blocks; we have two kinds of blocks - ones that look good when aligned to the edge of the browser window, and ones that don't. It would be useful to be able to declare this in the block rather than having to list all the blocks in the theme.

[paaljoachim]

Thanks for opening this issue @scruffian Ben!
I will ping in @annezazu
As I believe aspects of this has likely showed up in calls for testing.