[WIP] Add background image support to group block #38784
Conversation
getdave
added
[Type] Enhancement
|
Size Change: +3.04 kB (0%) Total Size: 1.15 MB
ℹ️ View Unchanged
|
getdave
requested review from
jasmussen,
scruffian,
adamziel,
ciampo and
frontdevde
|
Impressive and fast work! Took it for a quick spin and seeing this:
There's some overlap with Cover here. Ultimately I do think we'll want background support in the Group block, and possibly many others, but one of the challenges is that the inspector controls for adding and managing backgrounds in the Cover block aren't yet that strong, and could use a great deal of refinement on their own. I recall that both @javierarce and @critterverse have done explorations in this area, and although #38577 deals with patterns, it speculates on other small iterations to the inspector. Group opens up the additional question of what happens when the group is empty? Cover handles that by adding a min-width. In other words, we know we need to improve the design controls for backgrounds, and it might be worth it to do that before we expand backgrounds to other blocks. That way, when we do we can potentially manage the complexity by making "Background" a hidden-by-default addition to various toolspanels. Although definitely not as convenient, it seems like Cover could work as an interim solution if you need it. What do you think? |
|
Thanks for your review as always @jasmussen 🙇♂️
Oh 100%. There is. But Cover
One of my concerns is that Group now has both background and overlay. Cover only seems to have overlay.
I'd say we leave it to do whatever it does naturally. If you decide to set a background on a Group but then don't add any content to that Group then it should behave as it does now but just with the background image displayed.
One of my goals here would have been to refactor some of the tools so that they are resuable and shared between the blocks. I assumed this would probably lead to them being picked up by someone working on Global Styles? Perhaps @jorgefilipecosta can advise on how he sees the situation with background image controls and how these might be abstracted in future.
IMHO it feels like we've had this [Cover block] as an "interim" solution for too long now. I raised the Issue in April 2019. Part of the reason for me raising this PR is to raise awareness of how long the Issue has been outstanding and how many folks are keen to see this feature land. If it turns out there is little appetite however, then we can close this out until background controls mature. I just fear that without something concrete to drive that effort forward we might be back here in another 2 years time 😄 |
|
Right now it seems we need to move forward with the next iteration of the background controls (featured image, video URL etc) for the Cover block and then bring these background controls onward to other blocks. At the same time it would be helpful to get a first iteration of the background controls to add an image into the Group block. As it has been a feature that many needed for a long time. |
|
This is an awesome PR to see being worked on! This is such a long-standing request in Gutenberg that has been approached in a lot of different ways — I just wanted to weigh in on some of the things that have prevented us from moving forwad in the past.
The way that the overlay works in the Cover block has always been a bit confusing IMO, and prevents us from having parity with other blocks like the Group if we were to extend background capabilities there. A good first step towards unblocking this PR would be resolving how colors work in the Cover block. I personally would love to see further steps taken towards a true "layered" Color palette (more robust functionality around the way the Color panel works has been proposed a few times in the past, including in @javierarce's excellent post Interaction of Color). The layered panel could handle both background color and overlay color, with items at the top of the panel representing the foreground and items at the bottom of the panel representing the background like a traditional layers palette.
Also agree with what @jasmussen said above about the Cover block background controls needing a good deal of refinement. @javierarce and I shared some explorations around this recently in #20193 (comment)
^ This is something that tripped me up when testing this PR. Because the Group block remains empty after adding media, it's difficult to select the Group block or get back to the toolbar in order to remove or replace the media. As others have already mentioned, my instinct is that it might make more sense to refine the functionality of the Cover block to a point we’re happy with, and then look at expanding those features for the Group block (and potentially other blocks). Whatever road we take to get there, very happy to see background capabilites evolving! |
|
Noting a counter argument here that the process of abstracting the commonalities before new background features are added to the Cover block might make it easier to have those features across both blocks. Also by stress testing against more than one block we might be able to design better UI and UX as well as more flexible and resilient components. Conversely, if folks feel overlay/background on the Cover isn't working well then let's not foist these problems on the Group block. Rather lets try and enhance the Cover block and then abstract to the Group block.
Wow this is awesome. @critterverse @javierarce is there any work actively under way to implement any of these ideas? If not are there any concrete plans or roadmaps pointing in that direction? |
There's not a specific roadmap or timeline that I know of — but I know that some of us on the Design team, including @jasmussen and @javierarce, have done a lot of thinking about background tools and are excited to see further capabilities take shape! I think we're in a much better place to think about implementing some of these ideas now than we were even a year ago, based on the work that was done in #27331 — so it would be good to revisit the Cover block sometime soon. I suggest that we link any design updates to this issue and #16479 to keep track of the conversation. |
Probably good to involve folks who worked on the |
|
There was a discussion thread started recently that looked to explore the possibilities around background block support. If our intent is to be consistent across blocks, I'd suggest this might be the best mechanism to achieve that. |
|
As great as adding further background functionality to more blocks will be, I'd like to strongly recommend that we hold off on this. Copying across the Cover block's functionality also copies its problems, introduces lots of new attributes, and modifies markup. All of which increases the complexity and maintenance burden. Managing deprecations as they currently are is a tricky and fraught process. We've only just recently seen issues and regressions with the Cover block around this area. @glendaviesnz and @ramonjd will be able to speak more on this. My vote would be to approach this taking into account the fact we do want this functionality shared across a number of blocks and implement a consistent solution that can be opted into by each block requiring only the bare minimum of tweaks to the blocks themselves. I appreciate the great desire and user demand for this but I do feel we can save a lot of headaches by pausing for a moment. Interested to hear others' thoughts. |
There was a problem hiding this comment.
Thanks for diving into this @getdave! I think it's a feature we'd all love to see in the group block.
Just echoing Aaron's linking to the discussion about a background block support — I think it's important that we take what we've learnt from the challenges in dealing with the complexity of the Cover block (and its many deprecations) and look into seeing if there's an abstracted background block support that we can build, instead of trying to duplicate logic between the two blocks. For example, a recent fix from @ramonjd for the Cover block involved updating 53 files, so it can be pretty tricky to work with!
At this stage I'm looking for feedback on feature parity with the Cover block.
So, rather than looking at feature parity between the Group block and the Cover block, I think it's a good time to ask, "What features of the Cover block are universal to any block where we might want a background?". There's a few other types of blocks that could also benefit from background images, including Column(s), Button, Media & Text. It'd be great to focus efforts on what will allow us to scale the support across any arbitrary block.
Port over save.js implementation from core/cover to allow for front end to reflect changes in editor.
Another thing to explore in developing a universal block support for background images, is to see how much of the logic we'd like to move to server-rendering, to both avoid the issue with deprecations, and also potentially to support dynamic values for background images (such as featured images), so it could also be a good opportunity to rethink how we save background image data.
Thanks again for pushing forward the discussion and opening the WIP!
Thanks for the ping. I'm in agreement, if only to spare our future selves the trauma of juggling backwards compatibility and deprecations when things change. Two recent examples are #38392 and #35065, where modest changes to the Cover Block sent us down a nightmarish vortex of fixtures, deprecations and test scenarios. I'm exaggerating for a laugh of course. Or am I? 😄 I like where this PR is going conceptually. It'll be fantastic to be able to offer theme authors the ability to customize block backgrounds. However as mentioned, there are other blocks that might benefit from background controls, so it might be worth considering a block supports approach. Something like that could even be extended to the theme/site level. Cheers 🍺 |
|
Thanks for the feedback everyone. Exactly what I was hoping to stimulate with this PR 😄 I agree that we don't want to naively copy/paste between Cover and Group as we do in this PR. In the spirit of working incrementally I was hoping to use the Group as an exercise to determine which parts of "background images" are universal and which are block specific. However, I will defer to your experiences with Cover which sound...challenging! Question: are you aware of anyone currently working on this feature? As I expressed previously, creating an all-encompassing "backgrounds" solution sounds optimal but we might end up back here in 2years time still asking why the Group block doesn't support background images (I'm being facetious but you take my point). Thanks again for all the great input. I appreciate your time 🙇 |
There was a problem hiding this comment.
Hi @getdave,
Thank you for working on expanding background tools 👍
The cover block is complex and I think we should not try to port all its functionality to other blocks. If one needs something with advanced backgrounds probably the cover block is a right to block to use. If we port things in the cover block to the group block the group block may essentially become a cover block. The cover block is not just a background image, it supports things like setting a background video with an overlay gradient changing the colors in the video, that is not something done purely with CSS and requires specific markup to work. There were even tries in the past to allow having embeds as backgrounds e.g: a youtube video as background but as it required loading third-party scripts we did not pursue that.
I think having basic image backgrounds purely based on CSS may make sense in other blocks. In that case, I agree global styles and block supports seem the right place. Blocks would specify they support image backgrounds on block.json, and one would be able to change the image background at the block level and at the global styles level e.g: setting an image background for the site.
We would only support what CSS supports with simple rules e.g: setting an image background without overlays, videos etc...
As far as I know, no one is working on these tasks, and is something that can be worked on.
|
Thanks @jorgefilipecosta for outlining the key differences between the cover block and how a background support might work. As far as I know work hasn't commenced on building a background support yet, but @glendaviesnz kicked off the discussion to see if folks have opinions on how it might work. I like the idea that a background support would be restricted to a fairly simple CSS approach, and deferring the more complex use cases to the Cover block.
It is easy for desired features (like this one) to sit around for a long time without anyone working on it directly. The group block (and block supports in general) has received a lot of attention recently, but more in terms of layout supports and how we render the position and flow of blocks (and colors) rather than the background images in particular. Sounds like background support could be a good candidate for someone to pick up now since it seems like there's quite a bit of interest in seeing it added! |
|
Thanks for adding in the discussion link Andrew! |
No problem. The idea of this (draft) PR is to stimulate discussion around a much requested feature and to provide evidence of a requirement for the functionality to exist.
Agreed. Indeed I have omitted the "videos" functionality from this PR. There may be other things we would wish to omit also.
I'm glad you say this because I don't think the Cover block is suitable in all circumstances. I'd like to see basic background image support added to the Group block. If other blocks can use it as well then so much the better. Let's explore that.
As per the 👍 on this PR, it looks like we have enough demand to warrant someone starting to work on this feature in a general (i.e. not block-specific) way as you describe. |
|
I've made a start exploring how a background image block support (that we could opt the Group block into) might work in a draft PR (#39243) — it's very early, but just thought I'd share that I'm looking into it since there's been so much interest in the feature. I'm hacking away at this around working on other things, so will continue chipping away at it as I have time, but I'm keen to explore implementing the feature. Happy for any feedback, of course! |
|
Wanted to mention a new ticket with a design for a single "Background" panel in #39427. It also features layers, but there are mockups for a more near term solution as well. |
|
We won't pursue the route in this PR now so closing. |
Description
As illustrated by the number of 👍 comments on #14744 there is user demand for the ability to set image backgrounds on the Group block.
This has been a long-time outstanding issue and with the standardizing of Global Styles it's now one I think we can look to address.
This PR is currently a WIP which simply copy/pastes the implementation from the Cover block to gauge interest in the feature.
Note: currently this only works in the Editor. The block will not yet output images on the front of the site.
Further work will proceed in phases:
save.jsimplementation fromcore/coverto allow for front end to reflect changes in editor.Feedback required
I'm looking for feedback principally on whether folks still want to proceed with adding background images to the Group block. Is it necessary? What alternatives are there? What technical problems do we need to solve?
One of the main technical problems is that the Group block was adjusted (by @youknowriad) to remove the inner
<div>element which we would probably need to restore if we proceed with this PR. Currently I've restored the<div>but we'll need to revisit it.Testing Instructions
At this stage I'm looking for feedback on feature parity with the Cover block.
Screenshots
Screen.Capture.on.2022-02-14.at.13-53-54.mov
Types of changes
Checklist:
*.native.jsfiles for terms that need renaming or removal).