Inner block supports and future plans

[luisherranz]

Maybe I missed this and it's already there but, are there plans to let blocks decide where they want to apply the CSS of some of the blocks supports?

For example, what if I want my block to support a background color but it should not be applied to the root HTML node, but instead to an inner node?

Also:

• Are there any plans to use Block Supports for things that require, not only CSS but HTML modifications? Again, maybe this already exists and I missed it.
• Are there any plans to use Block Supports for things that would require JS hydration in the client?

[mtias]

For example, what if I want my block to support a background color but it should not be applied to the root HTML node, but instead to an inner node?

Yes, it was scoped mostly in this issue: #28913.

[luisherranz]

Thanks a lot for the response Matías, and sorry for my late answer.

I've been taking a look at #28913. It's very interesting, thanks. It seems like it can provide more flexibility in that aspect. I still feel that I need to explore block supports more to understand the full scope of their usage and current design.

I've also stumbled upon this other @oandregal issue (#22887) that highlights the need to repeat block supports and contexts as block attributes to add typings and defaults, which is also interesting.

I wonder if we could find a way in the future to declare the attributes/supports/contexts directly in the DOM/template to solve this problem, but I don't have any specific idea right now.

By the way, regarding my questions about supports that require JS or HTML changes: Is this something that has been explored before, or is it open for exploration? 🙂

[mtias]

The thing with declaring them in the DOM/template is that it blurs the line between the block instance and the block type if it initializes with default values or serializes them.

One of the motivations for supports is to decouple them from markup as much as possible, so that they can be assembled as needed at any point. Requiring explicit markup changes to accommodate side effects would be tricky in that regard.

[luisherranz]

As I said, I don't have any specific idea about this yet, so I'm just exploring ideas... but I feel that an in-place markup declaration in some sort of template system could have some potential 🙂

For example, a button block could become something like this (block supports are implicitly declared and don't need to be repeated elsewhere):

<div @supports:color.background={$backgroundColor} @supports:fontSize>
  <a @supports:color.text @supports:border.radius="25px" @supports:spacing>
    {$attributes["content"]}
  <a/>
</div>

There are many many ways to design this, this is just one.

This would later be compiled to whatever code is necessary for WordPress to know what block supports are declared for this block and what HTML node they should be applied to.

The thing with declaring them in the DOM/template is that it blurs the line between the block instance and the block type if it initializes with default values or serializes them

What problem would you see regarding initialization in that example?

decouple them from markup as much as possible, so that they can be assembled as needed at any point.
Requiring explicit markup changes to accommodate side effects would be tricky in that regard

Could you share an example of that so I can understand the limitation?

[luisherranz]

Are there any plans to use Block Supports for things that require, not only CSS but HTML modifications?

Answering myself here, but I've been trying to think about this question and I cannot find a specific example of a styling capability that requires additional markup (or a modification of it). Maybe something that involves flex or grid...?

[luisherranz]

By the way, I think this @c4rl0sbr4v0's discussion is related to our conversation here: #36079

[luisherranz]

WP_Block_Supports::get_instance()->apply_block_supports();, returns an array with separated styles and classes.

Can you also access them separated by block support (like border, spacing, color...) so you can put each one in the correct HTML node?

[gziolo]

Can you also access them separated by block support (like border, spacing, color...) so you can put each one in the correct HTML node?

I don't think it's possible to access them by type. It's worth noting, that colors can be multiple settings like text, link, background or border (color). One idea I shared in a completely different discussion that I can't find now would be to provide scoping for block supports. By default, it would be the block wrapper, but you could define some custom scopes so in PHP you would have:

<?PHP

$wrapper_attributes = get_block_wrapper_attributes();
$scoped_attributes  = get_block_scope_attributes( 'my-scope' );

return sprintf(
    '<div %1$s><p %2$s>Some content</p></div>',
    $wrapper_attributes,
    $scoped_attributes
);

A related code in block.json could look as follows:

"supports": {
    "color": {
        "scope": "my-scope"
    }
}

[gziolo]

I left a comment with another proposal in #36079 (comment). I'm wondering now whether I should move it here and we should consolidate the discussion in this place.

[luisherranz]

Why not in #37495?

[gziolo]

That’s another option. I’m just trying to to figure out how to bring very similar discussuons into one place 😃

[oandregal]

👋 Saw the ping in #36079 and here. Thought I'd share the edge cases we've run into that the current block supports mechanism struggles to incorporate. It's mostly captured in this issue and the related links #33255

TLDR is that the current block supports targets a single area for styling (you can't have two different background colors, for example). While #28913 allow us to tweak that area via the CSS selector so we can address parts of the block other than the wrapper, it's still a single area.

[luisherranz]

Hey André, thanks for chiming in 🙂👋

While #28913 allow us to tweak that area via the CSS selector so we can address parts of the block other than the wrapper, it's still a single area.

You mean that is a single area when you use _experimentalSelector, because neither using property selectors as Ben suggested here or expanding the elements API as Aaron suggested here have been implemented yet, is that right?

If so, the current way to spread the different support classes/styles is by using the different experimentalSkipSerialization flags and their useXxxProps() counterparts, like in the Button block. Is that right?

---

By the way, in #33255 you mention the possibility of having custom styles and controls in the future:

There's some progress for the new UI for global styles at #32923 so work on allowing custom styles and controls may need to wait a bit.

So, is there a plan to allow custom styles? In other words, are there plans to make block supports extensible by plugins?

[oandregal]

There are a few interrelated concepts here:

• How styles & classes are serialized to the block. If a block uses the hooks mechanism, the values chosen by the user in the respective UI controls will be serialized to the wrapper automatically. You can "disengage" the automatic serialization mechanism and do-it-yourself via __skipSerialization. This is what the button block does.

• By "single area for styles" I mean that you can only have a single style type per block with the current block supports mechanism. For example, you can only have a single background color per block. So the question is, how do we allow more "background colors" per block?

One underdeveloped aspect of the current API is the "elements" of a block. While this works at the "global styles" level (theme.json and the global styles sidebar, see #34574 and this screenshot in particular), there's no similar concept yet for the "local styles" (block sidebar). Can elements be declared by a block and so its sidebar gains new areas for styling?

That's a promising path in my view. At the moment, we sort of have the footsteps for this: blocks can declare that they support link color and users will be able to tweak the text color of the link element. However, they should be able to do more: change the background color of the link element, change the typography of the link element, etc. If we add more elements (buttons, header, footer, etc.) that blocks can support, we're increasing the "style areas" of the blocks, if that makes sense :)

So, is there a plan to allow custom styles? In other words, are there plans to make block supports extensible by plugins?

Blocks can always have custom style controls by hooking into the edit function, etc. Though the issue with custom controls for the block sidebar is that we don't have a way to register them in the global styles sidebar yet. Folks shared concerns in the past against allowing custom controls in the global styles sidebar, as the main idea behind theme.json & the GS sidebar is to develop a system that works across themes. My personal view is that we should ship the global styles UI in 5.9 and listen to what the community says.

[luisherranz]

These are very interesting thoughts, thanks for sharing André.

Can elements be declared by a block and so its sidebar gains new areas for styling?

So the path you mention would be to let blocks express their styling capabilities using elements as the base unit, instead of block supports.

Instead of specifying where each block support should sit in the markup (oversimplified):

const Button = ({ attributes }) => {
  const colorProps = useColorProps(attributes);

  return (
    <div>
      <a {...colorProps}>{attributes.content}</a>
    </div>
  );
};

Specify which part of the markup represents each styling element:

const Button = ({ attributes }) => {
  const linkProps = uselinkElementProps(attributes);

  return (
    <div>
      <a {...linkProps}>{attributes.content}</a>
    </div>
  );
};

In one block, the link element can be the <a> tags, in other <button> tags, and so on...

If we add more elements (buttons, header, footer, etc.) that blocks can support, we're increasing the "style areas" of the blocks

When you refer to elements like header or footer, you mean semantic parts of a block, not HTML tags, don't you? Like for example, bear with me:

// block.json
{
  "elements": ["header", "main"]
}

Or even:

// block.json
{
  "elements": {
    "header": {
      "typography": {
        "fontSize": true
      },
      "color": {
        "link": true,
        "background": true
      }
    },
    "main": {
      "spacing": {
        "padding": true
      }
    }
  }
}

const HeroBlock = ({ attributes }) => {
  const header = useHeaderElementProps(attributes);
  const main = useMainElementProps(attributes);

  return (
    <div>
      <div {...header}>
        <h1>{attributes.title}</h1>
        <img src={attributes.src} />
      </div>
      <p {...main}>{attributes.content}</p>
    </div>
  );
};

Well, sorry because that example is a bit rough, and it has a few problems, like:

• What happens with elements inside RichText generated content, like links?
• What happens if you need to spread supports from one element between different HTML nodes?

So maybe using selectors would be a better way to handle the spread, as Ben proposed. Something like:

// block.json
{
  "supports": {
    "header": {
      // General selector for the header element.
      "selector": ".wp-block-hero__header",
      "typography": {
        "fontSize": true
      },
      "spacing": {
        "padding": {
          // Specific selector for the padding styling of the header element.
          "selector": ".wp-block-hero__header h1"
        },
        // This will fallback to the general selector.
        "margin": true
      }
    },
    "main": {
      // General selector for the main element. Optional.
      "selector": ".wp-block-hero__main",
      "spacing": {
        "padding": true
      }
    },
    // With no selector, this will fallback to the block root.
    "color": {
      "text": true,
      "link": true
    }
  }
}

const HeroBlock = ({ attributes }) => (
  <div {...useBlockProps()}>
    <div class="wp-block-hero__header">
      <h1>{attributes.title}</h1>
      <img src={attributes.src} />
    </div>
    <p class="wp-block-hero__main">{attributes.content}</p>
  </div>
);

Anyway, examples are not important, I'm just trying to see if I start understanding the current status and plans forward of each Gutenberg API. Let me know if this is the idea 🙂

So the question is, how do we allow more "background colors" per block?

Are there any plans for this or is it still in the making?

[cbravobernal]

If this can help with the discussion giving more context. Here we have an example of applying different styles to different components both in JS and in PHP.
Feel free to discuss about it.