add box-shadow support for blocks via theme.json

[madhusudhand]

What?

This change will add box-shadow support for blocks in theme.json

Why?

Currently it is not possible to add box-shadow to a block such as buttons or groups, and having the support will eliminate the need to add custom css in block themes.

How?

It is the simplest form of implementation to support box-shadow through theme.json

1. included new 'box-shadow' prop in PROPERTIES_METADATA
2. also included it in VALID_STYLES

This implementation accepts box-shadow as a string as per the CSS Spec

Testing Instructions

In color section, add a new property shadow to any block.

{
  ...
  "styles": {
    "elements": {
      "button": {
         "shadow": "10px 10px 5px 0px rgba(0,0,0,0.66)"
      }
    }
  }
}

Screenshots or screencast

Further thoughts and questions

Before this approach, gave it a try to add support for an object as follows instead of a string value.

"shadow": {
  "color": "lightgreen",
  "hOffset": "10px",
  "vOffset": "10px",
  "blur": "0px",
  "spread": "5px"
}

However the box-shadow doesn't have any longhand properties to configure. Yet it could be solved by assigning them to css variables and constructing box-shadow out of them.

'--wp--style--shadow-color'	=> array( 'shadow', 'color'),
'--wp--style--shadow-h-offset'	=> array( 'shadow', 'hOffset'),
'--wp--style--shadow-v-offset'	=> array( 'shadow', 'vOffset'),
'--wp--style--shadow-blur'	=> array( 'shadow', 'blur'),
'--wp--style--shadow-spread'	=> array( 'shadow', 'spread'),

It works, and it will be in the same style as that of border. However it supports only single box-shadow. 😞

why do we need to support multiple shadows.

multiple box shows to solve the scenarios like

Double border effect with multiple shadows

box-shadow: 8px 8px 0px -2px white, 8px 8px 0px 0px green

Or A much smoother shadow with the help of multiple shadows (instead of border and shadow)

box-shadow: 0px 4px 8px -2px rgba(9, 30, 66, 0.25), 0px 0px 0px 1px rgba(9, 30, 66, 0.08)

Any may more scenarios.

It would be simpler to use string to support multiple shadows. The UI (when implemented) should read the value, split it to appropriate values and render the UI, and vice versa.

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @madhusudhand! In case you missed it, we'd love to have you join us in our Slack community, where we hold regularly weekly meetings open to anyone to coordinate with each other.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[scruffian]

Have you given any thought to the options we would offer to users to create their own shadows?

[scruffian]

What do you think about providing a set of different shadows that users can select from - so they'd provide a string which we interpret in the back end?

[madhusudhand]

Have you given any thought to the options we would offer to users to create their own shadows?

Because the shadow is controlled by all the inputs it takes, I would imagine UI to have individual controls work best for the customisation.

1. hOffset
2. vOffset
3. blur
4. spread
5. color
6. inset or outset

The hOffset and vOffset could have limits between -100px to 100px in the UI.

1. They could either be individual bars to increase or decrease the values.

2. Or there could be a square that lets users choose x, y coordinates in the above range.

blur and spread could be represented as bars to choose the range of values.
color would be a copy of the existing color palette.
inset or outset could be a checkbox kind of option.

Even if we decide to implement a totally different UI, ultimately it has to create the raw shadow string of the above definition. So, it should not have an effect on the current implementation.

What do you think about providing a set of different shadows that users can select from - so they'd provide a string which we interpret in the back end?

It's a good idea to provide users with set of pre defined shadows. But instead of enabling named strings as values and parsing them in the backend, I would say its best to keep the actual values or CSS variables, it might be difficult for users to imagine the shadow by looking at name I guess.

We could show them like a gallery view, and when selected save the final css string.

This also gives me another idea, does it make sense to define a separate section under settings like we do for color palette?

A theme can define set of predefined shadows in addition to what comes from GB and lets users to choose any of them from UI.

[scruffian]

Thanks for all the work here, there's a lot of useful exploration...

This also gives me another idea, does it make sense to define a separate section under settings like we do for color palette?

This seems like it might be worth exploring but I think it would be good to get feedback from @mtias before going too much further...

[scruffian]

I think this is going in a good direction, just a couple of suggestions:

1. We should make this an opt in property like the others, so blocks would have to set shadow to true in their block supports, in block.json. Then we should restrict it to only the group and button blocks for now, and button elements.
2. I'm not sure this makes sense under color. Could it just be a top level setting called shadow?

[madhusudhand]

This is ready for another review.

[scruffian]

I see this warning: Warning: array_keys() expects parameter 1 to be array, null given in /var/www/html/wp-content/plugins/gutenberg/lib/compat/wordpress-6.1/class-wp-theme-json-6-1.php on line 156

[scruffian]

This is working well on the frontend and the post editor:

but not in the site editor:

[madhusudhand]

@scruffian Is there a filter on the Editor Frontend (react) ?
I see that php returns the shadow value to browser and I guess it is removed while transforming the css with .editor-styles-wrapper prefix.

inside the script block

.wp-element-button,
.wp-block-button__link {
    background-color: var(--wp--preset--color--foreground);
    border-radius: 999px;
    border-color: transparent;
    border-width: 1.5px;
    border-style: solid;
    color: var(--wp--preset--color--background);
    font-family: var(--wp--preset--font-family--spacemono);
    font-size: var(--wp--preset--font-size--medium);
    font-weight: normal;
    line-height: 2;
    padding-top: calc(0.05em + 2px);
    padding-right: calc(1.333em + 2px);
    padding-bottom: calc(0.05em + 2px);
    padding-left: calc(1.333em + 2px);
    text-decoration: none;
    box-shadow: 5px 5px 0 0 red;
}

Final transformed style

.editor-styles-wrapper .wp-element-button,
.editor-styles-wrapper .wp-block-button__link {
    font-family: var(--wp--preset--font-family--spacemono);
    border-color: transparent;
    border-style: solid;
    border-width: 1.5px;
    border-radius: 999px;
    color: var(--wp--preset--color--background);
    background-color: var(--wp--preset--color--foreground);
    padding-top: calc(0.05em + 2px);
    padding-right: calc(1.333em + 2px);
    padding-bottom: calc(0.05em + 2px);
    padding-left: calc(1.333em + 2px);
    font-size: var(--wp--preset--font-size--medium);
    font-weight: normal;
    line-height: 2;
    text-decoration: none;
}

[MaggieCabrera]

I think this is where we are appending that class, @madhusudhand

[madhusudhand]

This is working well on the frontend and the post editor, but not in the site editor:

@scruffian @MaggieCabrera Fixed the issue with site-editor. This is ready for another review.

[scruffian]

This is looking good, but I'm having some trouble testing. Please could you rebase the branch from the latest trunk?

[scruffian]

LGTM