Size Change: +1.25 kB (+0.02%)

Total Size: 7.69 MB

_{compressed-size-action}

Flaky tests detected in 0567753.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/23574013872
📝 Reported issues:

• [Flaky Test] Should render and migrate legacy openSubmenusOnClick blocks #75559 in /test/e2e/specs/editor/blocks/navigation-frontend-interactivity.spec.js
• [Flaky Test] post title and content are editable and blocks can be inserted #76524 in /test/e2e/specs/editor/various/post-content-focus-mode.spec.js
• [Flaky Test] should show correct homepage actions based on current homepage or posts page #68892 in /test/e2e/specs/site-editor/homepage-settings.spec.js

Just noting that their might be additional unexpected use cases to drive the need for this improvement for background support.

To implement text gradients we can't be modifying the shorthand background property in color.gradient supports at the same time as modifying the backgroundClip support as it will throw errors in the editor.

Leveraging this background.gradient support which uses the background-image CSS property allows the text gradient control in #76171 to update the block support values required by the text gradient control.

Just a quick update here to note that this proposed background.gradient support would be required to unblock work around supporting text gradients due to React throwing errors in the editor due to the color block supports use of the shorthand CSS property.

Thanks for the discussion everyone 🙇

The downside is that for basic paragraphs, this adds a whole 'nother panel, with just a single item inside. But semantically, it feels more scalable, especially if we want to expand the block supports for image and gradient to additional blocks.

@jasmussen there's a good chance that paragraph blocks will not only have a single item inside for long.

With #76171 and planned follow-ups, the paragraph block would also get the background image and optional clip control. So it will fill out more rather than appear as an afterthought.

Additionally, perhaps it would be better then for #76171 if the "text gradient" selection were its own control rather than a gradient tab within the text color popover and "Foreground" panel.

The challenge is the labels, and the taxonomies. It doesn't make sense to have "Background image" as a panel, when "Background" is a swatch inside the "Color" panel. It's mixing things up a bit, and it deserves a change that gathers all background tools together. Before and after:

The renaming of the Background Image panel to Background was proposed here. I initially didn't include it here mostly in that all the current background controls were all still background images (including gradient)

I intended to seek design feedback there to settle on a course of action for the Color panel.

Reworking the Color panel's background to the Background panel and renaming the panels themeselves might be best as an immediate follow-up to this.

Reworking the Color panel's background to the Background panel and renaming the panels themeselves might be best as an immediate follow-up to this.

This PR is slightly related, though it might be outdated:

#74386

Thanks for sharing that link @ramonjd, I missed adding it 👍

I'm starting to wonder if we should also give the background color the same treatment as the background gradient here.

I mean, in this PR we are creating a new block support so that we can assign the resulting style to a new CSS property free of backward compatibility concerns. If we did the same, creating a background.color support to replace color.background, we could be free of the use of the shorthand background CSS property styles that have caused so many issues.

If we complete the process to shift away from the shorthand background property, I wonder if there'd be benefits in creating a new theme.json version which would migrate the old color.background and color.gradient values and settings to their new background counterparts.

With #76171 and planned follow-ups, the paragraph block would also get the background image and optional clip control. So it will fill out more rather than appear as an afterthought.

Nice. That said, as a tools-panel I'd default those controls to not show by default for paragraphs. The fact that we show background by default is already slightly a stretch since it's a much better user experience to set a background on a container.

Additionally, perhaps it would be better then for #76171 if the "text gradient" selection were its own control rather than a gradient tab within the text color popover and "Foreground" panel.

I actually still think that a tab inside the popover is the best path forward for this, and one that organically matches the term "foreground" very well. It's a separation of concerns, and it follows design precedence: items in the background panel already have gradient tab, now items in the foregrond panel do as well. It even makes it potentially simpler to add background images to foreground items; we'd need a redesign of the tabs to fit it (perhaps towards icons), but it's a good place to put them.

I think the strongest reason for having these separate panels for foreground and background is actually the parallel layering conversation. If we are embracing that for backgrounds you can layer solids, gradients, and images, and eventually reorder them, then potentially we can do the same for foregrounds. It's a stretch, but layering a solid and a gradient for text feels reasonable to me.

Let me know if there's any nuance I'm missing.

I greatly appreciate the feedback and thoughts @jasmussen 👍

I actually still think that a tab inside the popover is the best path forward for this
items in the background panel already have gradient tab

I'm a little confused here. This PR adds a Gradient control within the Background panel, but it isn't a tab within a popover; it's a standalone control. Clicking it opens a gradient picker within a popover.

The tab-in-popover pattern is specific to the Color panel's Text control, where solid and gradient are presented as tabs. So I'm not sure there's symmetry yet between the Color and Background panels.

Your mockup also appears to show color and gradient as separate controls within the Color panel, which is closer to what I was proposing

Could you clarify your preferred path forward?

Oh that's right, that conflicts. Apologies for that confusion, let me clarify.

The background tab works well if you want to add background-clip + gradient support to text in a small PR, soon.

The separation of panels feels like a larger endeavour, and if the foreground proposal resonates with @WordPress/gutenberg-design, it would give us this:

We could still use the ToolsPanel defaults to reduce it to this by default:

The above path would negate the ned for tabs inside the flyouts. I think it might be more discoverable and strike a good balance, but I'd love design validation. @jameskoster @fcoveram do you have instincts?

The inverse path is interesting, though, and deserves exploration. What if we maintained a single "Color" panel, that included text and background items? It would be something like this:

It's more compact in the inspector, and notably the above precludes us from allowing layer reordering as proposed here.

If I had to choose between these, I would go with the separate panels, and these defaults:

Because the vision for this could be like so:

That is, several layers, even multiple stacked gradients, to match what is possible in CSS.

What do you think?

What do you think?

I personally prefer the separate panels.

The ability to scale with the forward compatibility is a big win. The discoverability will be great for new or less advanced users. And finally, the Image tab within a Color panel popover doesn't fit as neatly, but maybe it's just my particular blend of OCD though 🤷

I've already started playing with an additional PR that will separate the panels as proposed here. I'll link it as soon as there is something tangible for people to play with and see how it feels.

It's only been quickly thrown together but there's a proof of concept over in #76474 that introduces a new background.color support so we can finally get rid of the troublesome background shorthand CSS property from block supports.

That new block support follows the same general approach as the background.gradient support to avoid backward compatibility issues with the color.background support which can be slowly deprecated.

This has all been wrapped up in a refactor of the panels to the proposed Foreground and Background panels.

Here's a rough demo, but I think we can continue discussion on that broader panel refactor to #76474 and keep this PR discussion back on the background gradient UI in particular.

It seems like we have buy in for the general direction all of this is taking. So in the next week or so, I'll look to start getting these base PRs and explorations in shape to merge. Starting with this one.

At a glance, I like that a lot. But I would also love validation at this point. @WordPress/gutenberg-design, notably @jameskoster @fcoveram perhaps. 🙏

For anyone else following along, the work in the following PRs, including this one, likely need a general direction to be settled on before we can progress them much further:

• Block Supports: Add background gradient support that can combine with background images #75859
• Block Supports: Add background clip support and combined UI for text gradient selection #76171
• Block Supports: Add background.color support and refactor foreground and background panels #76474

Depending on general confidence in the UI, we could look to land the first two PRs above with the view to iterate on them quickly.

Depending on general confidence in the UI, we could look to land the first two PRs above with the view to iterate on them quickly.

I'll take a look this week. Do you think it's worth getting a draft iteration issue up for 7.1, something like #73772?

No action required - just asking if it's worth it 😄

Just tested again and I think the approach here makes sense.

Moving gradient into the background property group seems like the right call to unblock the gradient + image combo.

A new tracking issue for design tools and block supports was created over in: #76525.

This covers adoption of some recent block support additions such as width and height as well as these new features around text gradients, background gradients, clipping etc.

Moving gradient into the background property group seems like the right call to unblock the gradient + image combo

I'll get a backport for this PR up soon and polished this up ready for a proper review.

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: aaronrobertshaw <[email protected]>
Co-authored-by: ramonjd <[email protected]>
Co-authored-by: jasmussen <[email protected]>
Co-authored-by: paaljoachim <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

This is generally working well, and I think we should aim to land soon!

I know you've thought about this in terms of migrations, but I wondering what the logical path for existing background styles would be.

In the editor, I have an existing gradient on a block (from trunk), then I add another (on this branch). The two gradients appear and clearing one or the other "appears" to clear the styles completely.

The frontend carries both:

The frontend, nevertheless behaves as I'd expect despite all this.

Thanks for the continued testing @ramonjd

I'm thinking part of what we are seeing is that the style engine still processes whatever styles are thrown at it. We need that for backward compatibility though so perhaps we need to tweak the color block supports to filter out the old styles if the block supports the new background.gradient support.

I'll explore this angle a bit and update accordingly.

I think I might have an approach that avoids the need for block deprecations for blocks adopting the new background.gradient support.

Blocks with style.color.gradient set from before this support existed remain valid as-is. When the Background panel renders, if background.gradient isn't set yet, it falls back to color.gradient for display so the existing value shows up in the right place. The first time the user interacts with the gradient control, the value gets migrated atomically — color.gradient is cleared and background.gradient is set in a single setAttributes call.

The has-background class is a bit of a special case. Historically, whenever a background color or gradient was applied this class was injected which often resulted in default padding for the block. During migration, we carry it over into the block's className when a gradient is being set. If the gradient is later cleared, we strip it back out so it doesn't hang around on a block with no gradient. Avoiding, always applying the has-background class finally gives us the ability to avoid this default padding and lean on global styles etc.

On the PHP side, colors.php normally emits a background CSS declaration for color.gradient values. When a block supports background.gradient and has a value set there, we suppress that so background.php can own the CSS output without the two conflicting. For content that's never been through the editor, color.gradient CSS still gets emitted as normal, so existing published content keeps rendering correctly.