Section style slugs

[richtabor]

With section styles landing in WordPress 6.6, let's talk about standardizing the slug values within Twenty Twenty Five.

Proposal

I've experimented with the Assembler theme, settling on is-style-section-1, is-style-section-2, slugs—as not every color variation has a "light" or "muted" or "dark" style (as some theme style variations are brighter, darker, or more minimal than others).

I've found that using a more generic slug will allow for section styles to be more meaning across multiple theme style variations—and also other themes—much like how spacing presets work.

Twenty Twenty Five is a great opportunity to showcase color and typography, especially with section styles across many color variations; we need to account for the variety of color-only theme style variations that may be included in the theme.

We could potentially leverage the pattern directory to make Twenty Twenty Five's patterns available for all WordPress installs leveraging the block editor, which would mean a standard for section styles could be interoperable across any site—no more colors that are fixed in a pattern.

Visual

Section styles, as applied to each pricing table here:

[richtabor]

Here's a case where the default muted, light, and dark section styles would map great—but if a color variation is much more expressive, then those slug values are much more confusing:

1.mp4

[bgardner]

Noting this is also being discussed at: WordPress/gutenberg#63036

[bgardner]

I love the movement toward an interoperable (instead of opinionated) approach and want to adopt whatever we decide here/TT5 in my work with Powder Studio. I can't think of anything better (or more suitable) at the moment than the generic section-1, section-2, and section-3 approach for slugs. This naming convention gets my vote.

[justintadlock]

Agreed that setting a standard convention here with Twenty Twenty-Five would help the theming community in terms of interoperability and documentation. I'm in favor of section-1, section-2, etc. for these sort of generic sections (you can always change the label/title). I've been testing with these slugs over the past few weeks, and it's worked well across a variety of designs I have.

I also used this method when naming slugs in the Dev Blog post about section styles (I'm happy to update if we go a different direction).

[MaggieCabrera]

I think there will always be a discussion as to how one type of wording is more semantic than another. This approach also has the benefit to translate way better into other languages.

[dballari]

I'm also in favor of generic slug naming for section styles. Like in spacings. Like, maybe, in all presets, even in colors.
Maybe, someday we could find that all presets naming does not need to be semantic, but standard across themes. There is always the possibility to define a second layer of 'pseudo presets' in the custom theme.json section (just for a particular theme) and make this one semantic. I tried to start doing this in a theme of mine with colors, but I did not finish. If I ever do finish, I'll share. It simplifies the creation of variations.

[carolinan]

Can we adopt a similar naming policy for custom block styles that are only applied to one block? Perhaps style-1 is too generic? I mean that not all styles will be applied to a whole section with inner blocks.

[bgardner]

As @richtabor mentioned on our call yesterday, that would generate this: .is-style-style-1, .is-style-style-2, etc which might be weird or confusing.

I know because I suggested the same thing with the the same reasoning as you @carolinan. But when he pointed out the above, I thought... Meh, probably not a good idea.

[carolinan]

What about custom-1?

[dballari]

By the way, I would even unify the slug and the title and would set both to Section. In my opinion, when words are not too technical there is no need to use a word in the front end different than the technical one in the code

[MaggieCabrera]

We should work on Create Block Theme to add support for section styles so they are easier to create without having to code