Size Change: -3.99 kB (0%)

Total Size: 1.75 MB

_{compressed-size-action}

There are some seriously undesirable gymnastics involved in getting background (color.gradient) to merge with the CSS background-image property.

Presets have !important so a gradient's class will override all background-* CSS rules. Not great, hey 😅

Variables include, a block has a:

• preset gradient only, then don't do anything
• preset gradient + image, then merge into background-image and remove background CSS declaration and any preset classnames
• image only, then don't do anything
• custom gradient + image, then merge into background-image and remove background CSS declaration

The UX is not great either because it seems random when a background image can be used with a gradient. Hint: it's only visibly beneficial where there are alpha values in a gradient to allow the image to be seen underneath.

I'm starting to think a change in the UI might be worth an experiment, whereby we merge the gradient and background image controls and control the styles from one location.

Not sure. It's a bit of a mess.

I'm starting to think a change in the UI might be worth an experiment, whereby we merge the gradient and background image controls and control the styles from one location.

Fooling around with this today, here's my current thinking about an iterative way to extricate Gutenberg from the background gradient conundrum:

The problem

Gutenberg currently uses the background shorthand CSS property for gradient backgrounds (color.gradient).

The shorthand CSS property overrides sub properties as detailed in this issue: #60401

Gradient backgrounds should use the background-image CSS property.

Unfortunately, that's now being used by background.backgroundImage.

So, Gutenberg needs a way to:

1. Migrate gradients from background to background-image.
2. Deprecate color.gradient over time.
3. Merge background gradients and images under background-image.
4. Ensure gradient presets continue to work in an intuitive fashion when used alone, but their classnames are ignored when combined with background images.
5. ??

How to tackle the problem

Background images are out of the bag, but site-wide background images and theme.json are not yet in WordPress.

1. One option is to delay this until we migrate/deprecate color.gradient and it's stable.
2. Another is to integrate a gradient control into the background image control UI, and do the rest iteratively. That way we can make calls about a UI that incorporates gradients and background images, as we ultimately merge values into one background-image CSS property.

The following headings and text relate to the second option.

Why integrate gradient and background image?

They should both apply to the same property — background-image.

What about the current background gradient UI control and the value of color.gradient?

In the first iteration, they stay.

That means it'll be possible to add a background gradient via the color and the background UI controls, the important difference being that the color UI control applies the linear gradient to the background CSS property, whereas the background UI control applies background images and linear gradients to the background-image CSS property.

As part of the first iteration, the background style object will receive a new property: background.gradient.

In the next iteration, I think the following should occur:

• the current gradient UI controls should be removed in the editor and the color.gradient property deprecated.
• Gutenberg maintains color.gradient support for backwards compatibility, e.g., it continues to render linear gradient values using the CSS background property.
  1. Blocks: for content with existing color.gradient values, Gutenberg should migrate them over to background-image if and when a background image/gradient is added in the editor using the background controls.
  2. Theme.json styles: existing color.gradient values function as they are unless a background image is also specified either in theme json or in the site editor (user styles). In this case the two values will be merged into background-image Example

The problem of theme.json gradient presets

Gradient presets generate classnames and CSS rules whose declarations (background: linear-gradient(...)) are marked as !important.

Blocks with gradient backgrounds have these classnames, which means the background property overrides any subsequent background-* declarations.

Where a block has a background image AND a gradient preset, these classnames should be removed from the block attributes, and the value of the preset merged into background-image. Example attempt.

I'm probably missing a lot. 😄

Nicely laid out @ramonjd! One of the things I really like about the description of the problem is that the proposal plans forward for how to integrate the two when a user does something (adding a gradient or background image). Since gradients are widely used right now, planning this in a way that preserves backwards compat by not trying to migrate any older markup, but just support things as-is, I think is a good path forward.

Just to add one more thought, if we were to pursue support for layers in the background (i.e. multiple images or multiple gradients) how might that affect the shape of the style.background object?

Just to add one more thought, if we were to pursue support for layers in the background (i.e. multiple images or multiple gradients) how might that affect the shape of the style.background object?

Excellent question 😄

There's nothing (aside from the safe css filter at the moment) preventing users from using the string value of background.backgroundImage to do this manually.

But parsing and integrating these values with the editor would be tricky so I agree it'd be good to plan it out.

One option could be that background.backgroundImage supports another key -background.backgroundImage.gradient.

The two could be exclusive, so either:

		"background": {
			"backgroundImage": {
				"source": "theme",
				"url": "img/untitled.jpg",
			},
		}

Or

		"background": {
			"backgroundImage": {
                                  "gradient": "linear-gradient(...)",
			},
		}

Then the "backgroundImage" key could support arrays:

{
	"$schema": "https://schemas.wp.org/trunk/theme.json",
	"version": 2,
	"styles": {
		"background": {
			"backgroundImage": [
                                 {
				     "source": "theme",
				     "url": "img/untitled.jpg"
			         },
                                  {
                                      "gradient": "linear-gradient(...)"
                                  }
                          ],
			"backgroundPosition": "center center",
			"backgroundRepeat": "no-repeat",
			"backgroundSize": "cover"
		}
	}
}

This would result in:

:where(body) {
    background-image: url(http://....untitled.jpg), linear-gradient(...); 
    background-position: ...
    ....
}

"gradient/url" exclusivity doesn't have to be mandatory, but it could avoid overloading/order problems.

This is just one idea I came up with in 10 mins - I'm sure there are better ones!

Then the "backgroundImage" key could support arrays:

Oh, interesting idea! I wonder if we'd want to move the array one level up? It looks like background-position also supports multiple backgrounds, so if folks were deliberately wanting to layer and position multiple images, we might need to support other properties, too?

Oh, interesting idea! I wonder if we'd want to move the array one level up? It looks like background-position also supports multiple backgrounds, so if folks were deliberately wanting to layer and position multiple images, we might need to support other properties, too?

Oh yeah, good call. 🎉

Unless I'm missing something, the advantage of supporting two types is that it's possible to implement it later even if the current object structure makes it to core.

Unless I'm missing something, the advantage of supporting two types is that it's possible to implement it later even if the current object structure makes it to core.

Yes, that's my understanding, too 👍