Share examples of how you hope to use section specific styling

[annezazu]

Pulling from this last week's hallway hangout on WordPress 6.5, I wanted to create a place where folks could share feedback about the ways in which they imagine using section specific styling to help shape the present and future of this feature.

What is the feature?

Through extended block style variations, theme authors will be able to more effectively style sections of pages and templates that differ from that block's global styles without having to repeat the same configurations over and over e.g. styling darker sections on a page. This will include the ability to style elements and inner block types within the block style variation.

That feature's functionality then essentially solves the main user need for colorways and typesets on individual block instances or "sections".

The composability of colorways and typesets holds the most value at the theme or "root" level of Global Styles, as in addition to unlocking a wide array of possibilities, it will assist users in more quickly achieving an overall look and feel for their site that they are pleased with.

The benefit in composable colorways and typesets on individual blocks or sections may not warrant the increased complexity and additional work required from a UI perspective. Especially given move powerful block style variations meet the same need.

How do you imagine using this?

If possible, please help review the current state of this work and consider what limitations come to mind. cc @fabiankaegy

[annezazu]

cc @WordPress/block-themers for good measure :)

[richtabor]

I would appreciate being able to style patterns with "section styles" rather than including the actual HEX values (or even color presets) within the pattern markup.

This way the pattern can be reused across all themes that define these section styles, and will always look ace—as each theme decides what those variations of color are.

[fabiankaegy]

I can see the value and beauty in this. The thing that worries me about the goal of cross theme compatibility of the section styles is that I don't see how such a system can woe without limiting the amount of the styles to a predefined set which will mean if you need more / different options you are out of luck 🤔

I would kind of love to approach this the other way around. Where a theme could defile the pattern from the pattern library it wants to pull in and then additionally maps which of its unique style variation it wants to use for the pattern.

[richtabor]

The way I see is, a theme decides what is-style-section-specific-1 means (nomenclature aside). If theme A makes it bright red, and theme B makes it bright blue, it's all good.

Patterns could have is-style-section-specific-1 assigned to the top-level group block, making all the contents styled however the theme depicts.

[fabiankaegy]

@richtabor but even with this, how would you resolve one theme having 3 of these and another having 6?

I just don’t quite see how this “random” mapping between themes can create a good user experience.

And for the pattern library, does this mean that some patterns don’t show up for a theme if it doesn’t have that number or style variations available? 🤔

[richtabor]

If theme 3 doesnt have any variations, it's totally cool — it's not intended to have patterns with variations if they're not defined as such.

It's not random, it's quite intentional actually. If a minimal theme only has one section specific variation, it's not intended to have lots of variation. And quite the opposite for a more playful theme, which may have four different variations. When you activate that theme, those same patterns from the directory would showcase a wide variety of color based on the theme's.

All we need to do is apply a variation to the patterns in the directory. You can have a pattern with a style variation class, and not define that class in the theme (no variation in theme.json). That's totally fine.

Instead of forcing themes to render X number of section specific styles (variations), they only render what's defined in the theme.

[fabiankaegy]

When I first heard about the idea of section specific style variations this came to my mind:

Having the ability to essentially use all of the style options available in theme.json but apply it to only a specific section.

Meaning you would be able to fully customize the style of any nested block within that section.

Kind of like Figma tokens work where you can create alternate variations of tokens and then when you move an element from one section to another section it changes all its styles based on the container.

[aaronrobertshaw]

Having the ability to essentially use all of the style options available in theme.json but apply it to only a specific section.

This was part of the original goal in styling sections.

Exploring the extension of block style variations as a mechanism to achieve this revealed a few specificity issues that are blockers to utilizing 100% of the style options in theme.json.

An example issue would be if we defined element styles, within block type specific styles, in a variation/section, they'd end up incorrectly taking precedence over the element styles a user might select on an individual block instance. Increasing the specificity of instance element styles to counter that would also be a breaking change.

Meaning you would be able to fully customize the style of any nested block within that section.

Would being able to customize a variation's (root) element styles and inner block type styles (without the ability to define elements within these block types) be enough to achieve the sorts of styling you're envisaging?

[fabiankaegy]

@aaronrobertshaw Thanks for sharing all those insights :)

Meaning you would be able to fully customize the style of any nested block within that section.

Would being able to customize a variation's (root) element styles and inner block type styles (without the ability to define elements within these block types) be enough to achieve the sorts of styling you're envisaging?

Hmm 🤔 Good question! I think one of the first things that comes to mind is needing to adjust the element styling of links inside sections because the hover style of anchors inside dark section needs to be different from the styles on a light version etc 🤔

[aaronrobertshaw]

Sorry, I wasn't 100% clear there. It's a tricky topic to convey all the nuances.

With the current approaches being worked through (#56540, #57908), you can define generic element styles for within a variation.

So for a dark variation, you could define links a lighter, readable color.

What I am suggesting wouldn't be supported is styling even more nested links a different color than others in the variation.

Excuse the rough pseudo code but imagine some block markup resembling:

Group with dark variation
    Paragraph
        Link
    Row 
        Group as a card
            Image
            Paragraph
                Link 1
                Link 2
        Group as a card
            ...
        Group as a card
            ...

We could define white as a link color within the dark variation and get some styles resembling .is-style-dark a { color: white;}. This is OK as the block instance element styles have the same specificity and are defined after the variation's.

If we wanted to define a different color, say green, for the links within the cards of the above example, by defining element styles for the dark variation's group block type, we'd get a style like .is-style-dark .wp-block-group a { color: green; }.

Now, if a user selected only the middle of those cards and chose to make it's links red, they'd end up with a style like .wp-elements-x a { color: red; } which would lose out to the previous style.

So the trick will be to somehow allow styling the links of those cards in an easier way than doing it for every block.

This is where being able to nest block style variations might help a little (but not 100%). In this approach you might define two block style variations, dark and dark-card. Each defines the link colors they want, but the card variation can be applied to the inner group blocks. Alternatively, a wrapper could be placed around the cards with a different variation for the links.

The ability to apply variations in a nested manner would also allow some other interesting combos.

I hope that clarifies things a little 🤞

[mike-henderson]

Currently we have to register pattern/component color variations with separate pattern files. If this control were in place we could cut down the amount of pattern files we include in the theme by moving these options to user selectable styling. For example, a text-media component will often have three color variations: primary, dark, light. This results in 3 pattern files with the same block code, with only the color attributes changing.

In certain instances, it is necessary to set the width settings as well. They are often set on wrapper blocks: group, column, or cover. Since the width options are really just a style variation, having this control available in the style section could be useful.

It would be nice to set the label of the section styling selection/variation. I imagine main variations for the theme that could be used across patterns/components could be set in theme.json but customized on a per pattern/component basis if needed. So we could set a “Primary/Default” style, have a dark style and a light style, etc.

I can provide specific examples if more clarification is needed, thank you!