Background image: update controls defaults and layout

[ramonjd]

What?

Maybe resolves #61928

This PR:

• harmonizes headings between block supports and global styles
• updates copy including changing the label "Fixed" to "Tile"
• uses horizontal layout for image size and repeat
• fixes bug where width input is cleared and the size defaults to "cover"
• tidies up the visually hidden context labels

Why?

Trying to bring some consistency to the controls.

Testing Instructions

... To come

Screenshots or screencast

[github-actions]

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: ramonjd <[email protected]>
Co-authored-by: jasmussen <[email protected]>
Co-authored-by: andrewserong <[email protected]>

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

[jasmussen]

Fast work, big improvement. Bug is fixed, and this is coherent with the Group option as well:

As I argue in this comment, I think we should also still change the default from Tile to Cover. The short summary of why is: until we have background-size and background-position tools to enable 2x resolution, and top/centered as opposed to top/left tiling position, "Tile" as a default is not going to be a good or expected experience.

That's not a blocker, so we can discuss this separately if need be.

[andrewserong]

This is testing well for me, too, and adds a nice level of polish. (Great idea @jasmussen to use the name Tile, too, it fits much better than Fixed, and allows for a true fixed option further down the track).

I think we should also still change the default from Tile to Cover ... That's not a blocker, so we can discuss this separately if need be.

On this one, I still feel like Cover for site wide backgrounds as a default risks leading users astray, so IMO a separate PR for switching the defaults would be a good way to go if we're planning to change it, as that way we've got the change clearly documented in its own PR.

This one LGTM! 🚀

[ramonjd]

I appreciate the test and feedback, folks!

I still feel like Cover for site wide backgrounds as a default risks leading users astray

I'm also for leaving it set to "auto" by default, but for different reasons.

For theme.json, I think we should be wary of inserting any default values that a user might not expect. My view is that theme.json should primarily represent positive intent, that is, "turn stuff on", rather than override opinionated CMS rules.

[ramonjd]

For theme.json, I think we should be wary of inserting any default values that a user might not expect.

Oh, and the backwards compat "fun" there'd be if folks ever wanted to change/roll back the default. 🤣

[jasmussen]

Thanks for moving fast on this one, also carefully. I did mention that I think Cover may be a better default experience, but as it turns out, I was misremembering aspects of this implementation, which in more in-depth testing reveals that, well, there probably really isn't any good default here, unless we add another bit of bundled default code, which I'll get back to.

My instinct was for Cover to solve these issues:

• It solves the low resolution issue without adding a background-size tool, and without precluding such a tool landing in the future.
• It solves the problem of defaulting to top/left alignment, where arguably most sites are top/center aligned, without adding a background-position tool.
• It solves the problem of images being huge on mobile, small on desktop, because it doesn't scale across.

Turns out I was thinking of the behavior of Contain, and even in that case, it only works with Contain + repeat, and then only for landscape images. Here's a case where that works well:

But even that falls apart if the image is portrait oriented. At that point it's still top/left aligned, but tiles horizontally.

For reference, here's the current default, Tile, which as noted has its own problems:

I'll dive back into #62046 with another suggestion, yet another new default!

[burnuser]

"Cover" would be the best default, when used like in good old Customizer as cover the screen (not the whole webpage!) in combination with "background-attachment: fixed"
(In fact I've never seen a website with a scrolling background image in real live.)

So, if there is no comparable solution to Customizer default, this feature is - in my opinion - not ready for WP 6.6

[ramonjd]

Thanks for the input @burnuser 🙇🏻

"Cover" would be the best default, when used like in good old Customizer as cover the screen (not the whole webpage!) in combination with "background-attachment: fixed"

Background attachment controls are in the works:

• Background: add background attachment to top level styles #61382

But it won't be part of 6.6 unfortunately. I'm working on this stuff as fast as I can 😄

As for the background-size: cover as the default, it's already the default for blocks (Group Block), but not for the site. It can be set in theme.json by specifying "backgroundSize": "cover", or via the Site Editor tools however.

In my opinion, we should be cautious about assuming defaults in theme.json in the absence of any values.

In the case of background size, the CSS default is "auto". For WordPress to assume "cover" universally might look fine for some images, but it won't for all. Furthermore, if, for any reason, that default needs to change in the future, then WordPress would have to continue to honor "cover" due to backwards compatibility forever.

So, if there is no comparable solution to Customizer default, this feature is - in my opinion - not ready for WP 6.6

There's a discussion going on how best background images in block themes can play with the current Customizer tool.

• Background image: should it integrate with background-image theme mod? #60939

The current state is that background images set via the Customizer will take precedence over those set in theme.json due to CSS specificity, so you can continue to use it without any interference from this new feature.