Add: Preset gradient functionality button block

[jorgefilipecosta]

Description

Implements: #16482
Related: #16662

This PR adds a set of Gradient related functionality and components and uses them to implement gradient functionality in the button block.
For now, we still don't have a custom gradient functionality we just have gradient presets.

Themes will be able to configure gradient presets. But we need a default set of gradients when themes did not pass their own set. I think this set is not very creative and we should look into having an awesome set :)
cc: @mapk, @kjellr

How has this been tested?

I added the button block. I used the gradient panel and I verified the preset gradients work as expected.

Screenshots

[senadir]

🎉🎉🎉🎉
Will test today & report back, thank you so much for working on this!

[senadir]

as per today's editor chat, there has been a discussion of whether we should use classes for gradients or directly inline them.

in my point of view, I think classes are the best, most compatible solution in case of updating & or changing the visual identity

[kjellr]

Regarding the default set of gradients: I think the main use case for this will actually be outside of the button block: for black(or white)-to-transparent gradients above images in the Cover block. If we plan on adding this functionality to that block, we should include those in this default set too.

For color ones, I think we should just choose a few subtle ones that are based on the default set of colors we use. So here's an example set:

• Pale Pink to Vivid Red
• Pale Cyan Blue to Vivid Cyan Blue
• Light Green Cyan to Vivid Green Cyan
• Black to White
• Black to Transparent
• White to Transparent

... each with a left-to-right and top-to-bottom variant. That would result in 12 swatches, which is coincidentally the same number that we include by default for colors today.

[kjellr]

Also yes, I think these should follow the standard set by colors: so these should be defined by classnames.

If we allow for users to create their own custom gradients later down the road, those would be inlined, just like the custom colors are today.

[mapk]

I think this set is not very creative and we should look into having an awesome set :)

In addition to some of Kjell's example above, I'd like to see a cool gradient and warm gradient if it's not too much. I can see these gradients being used as backgrounds to the Group block and Cover block.

Cool

• Vivid Green Cyan (# 00d084) to Vivid Cyan Blue (# 0693e3)

Warm

• Luminous Vivid Amber (# fcb900) to Luminous Vivid Orange (# ff6900)

as per today's editor chat, there has been a discussion of whether we should use classes for gradients or directly inline them.
in my point of view, I think classes are the best, most compatible solution in case of updating & or changing the visual identity

I'd also agree that classnames would be wonderful here. 👍

[jorgefilipecosta]

Hi @mapk, @kjellr, I updated the PR to use the suggested backgrounds.
We have now many predefined gradients. Should we also include some radial gradients (in that case probably we need to remove some of the current gradients)?
We have a problem right now we can not visually differentiate "Black to White" from
"Black to Transparent" as the background of the gradient picker is also white. Maybe we can try to add small png bellow as background with gray and white squares to indicate transparency?
Regarding the class usage, I update the attribute to be "customGradient" so right now we will always set custom values. This change allows us to quickly right after adding the classes mechanism. I'm not adding it right now because this PR is already huge and if I increase its size, even more, it becomes impossible to review.
This PR depends on #17154 which is pure code refactor I would like a review in that PR first so we can advance with this one :)

[kjellr]

Hi @mapk, @kjellr, I updated the PR to use the suggested backgrounds.

I think I'm actually still seeing the old colors here?

We have a problem right now we can not visually differentiate "Black to White" from
"Black to Transparent" as the background of the gradient picker is also white. Maybe we can try to add small png bellow as background with gray and white squares to indicate transparency?

Yeah, that makes sense. Something like this:

We could draw that grid as an SVG behind the gradient. Here's a sample SVG to try.

Trying this out, I'm wondering if it actually makes sense to have these exist in their own panel in the first place? Since these gradients are colors, I'd expect to find them appended to the rest of the color swatches:

[jorgefilipecosta]

Hi @kjellr,

I think I'm still seeing the old colors here?

Sorry, I missed to push my update it should be fixed now.

We have a problem right now we can not visually differentiate "Black to White" from
"Black to Transparent" as the background of the gradient picker is also white. Maybe we can try to add small png bellow as background with gray and white squares to indicate transparency?

Yeah, that makes sense. Something like this:
Frame 3

I will try to add this transparency mark.

Trying this out, I'm wondering if it actually makes sense to have these exist in their own panel in the first place? Since these gradients are colors, I'd expect to find them appended to the rest of the color swatches:

Soon we will have a custom gradients functionality I opted for a separate panel to not make a single panel very huge.
We could open the custom gradients panel in a Popover (although none of the designs proposed suggests that), but if we open in a popover we will need a Custom gradient button and custom color button and I'm not sure if having the two buttons is intuitive.
Having the colors and gradients together means 24 color options by default, I guess it may be too many options for a single panel.

[mapk]

I updated the PR to use the suggested backgrounds.

Looking through, I only see a few. Are we missing the gradients I had suggested earlier?

Here's what I'm seeing right now. I notice the color white by itself is included there. And two of the Black-to-white gradients are duplicated.

[jorgefilipecosta]

Looking through, I only see a few. Are we missing the gradients I had suggested earlier?

Hi @mapk the gradients you suggested Vivid Green Cyan (# 00d084) to Vivid Cyan Blue (# 0693e3) and Luminous Vivid Amber (# fcb900) to Luminous Vivid Orange (# ff6900) was there, but I wrongly set one of the transparency values the problem was fixed.

Here's what I'm seeing right now. I notice the color white by itself is included there. And two of the Black-to-white gradients are duplicated.

Hi @mapk the color white is White to Transparent, and one of the Black-to-white gradients is, in fact, a black to transparent. Both white and transparent were suggested as noted before we will need a way to indicate transparency (the typical white and dark squares). I hope to add this functionality very soon.
For now, to test if it gradients work well, we can nest the button inside a group and change the background color of the group.

[jorgefilipecosta]

The transparency indication was added now we can differentiate between white and transparent gradients:

Props to @kjellr for providing the transparency SVG!

[jasmussen]

I took the liberty of pushing a rebase, because it went smoothly and fixed some block registration issues that were otherwise present in master. However for some reason Github seems to still think there are conflicts with master, that I don't see in the checked out code.

Any idea what this might be?

[jasmussen]

I'm so excited for gradients to land, I took a stab at making a wider range of presets. The idea being that if we are launching V1 with presets ONLY, and not yet with a UI to customize those presets, it's important we launch with a range of high quality and widely useful gradients right off the bat. So I made these:

1. There are no duplicates for each direction. They are all top left to bottom right. The reason being that, arguably, these are easier to use. Also, it feels of more value to have a range of different gradients, than a bunch of confusing duplicates each with different orientations.

You could also see this as a bold first step and the next immediate step right after being to let you customize those presets using the UI outlined in #16662.

Props @onuro, as I used some of the gradients they provided in the sketch file on that thread.

2. There are a range of gradients built using the existing gutenberg palette, and a number of additional ones, some that feature multiple color stops. I also tweaked the capitalization a little bit to match the capitalization of those colors.

3. It removes the transparent gradients. Those can be cool, but they aren't that useful in the context of just the block. It's nice that the foundations for adding these (gray square pattern below), so let's add some like that, when this feature expands beyond the Button block.

Let me know what you think!

[mapk]

There are no duplicates for each direction. They are all top left to bottom right. The reason being that, arguably, these are easier to use. Also, it feels of more value to have a range of different gradients, than a bunch of confusing duplicates each with different orientations.

Excellent reasoning, @jasmussen! In the future we can add a gradient direction control as you noted.

It removes the transparent gradients.

Nooooo! Alrighty, I get your point. 😉 In context of the Button block, this makes sense.

[mapk]

From a design perspective, this looks like a great v.1.

[spacedmonkey]

It should be possible to define gradient in PHP using add_theme_support similar to editor-color-palette. Could I recommend editor-gradient-presets as a name.

[jorgefilipecosta]

It should be possible to define gradient in PHP using add_theme_support similar to editor-color-palette. Could I recommend editor-gradient-presets as a name.

Hi @spacedmonkey, yes the plan is for themes to be able to change the default gradient presents. When this is merged the following step is a custom gradient component and in parallel, we will add the theme API's editor-gradient-presets sounds like a good name to me, thank you for the suggestion 👍

[spacedmonkey]

Created a follow up issue here. #17774

[mmtr]

Button blocks with gradients are currently considered invalid blocks when loaded on multisite WordPress install. I created an issue with more context: #17938

[jorgefilipecosta]

Just for the record, a PR that addressed the button invalidation problem on WordPress multisite installs was recently submitted and merged #17940.
Thank you for reporting this issue @mmtr!