Hi!
So we got great new Background options.
How about a Slider? 
I generally don’t use sliders, but there is one type that can be very useful: The one with static content and moving background. I have actually managed to increase conversion rates few times with this concept, despite the fact that normal sliders are mostly conversion killers.
So the idea is to be able to add multiple images to a container background, and have them transition in few different ways at controllable time.
Thanks!
The Custom option allows shortcodes, so you could put something from slider plugin in there.
It’s hard to add a Slider option to the Backgrounds because it would be difficult to build the slides or control what they look like. As for native Slider functionality, our thinking is that we’ll probably make some kind of container element that lets you put whatever you want inside and enable slider controls. This would basically let you use Pro to build each slide, and on the parent you’d have controls over timing.
Once that is established, you could put it in a Div with pointer-events: none; that’s absolutely positioned inside any layout element. This would be the best way to achieve the same effect without custom plugins.
I’ve been waiting until this beta was over to bring up my older feature request for a V2 slider/carousel element. But since you brought it up…
I think it could be really powerful paired with the new looper controls. Users could build responsive, swipe-able galleries of posts – with 4 containers/columns on XL, 1 at XS (or people who want to build full-on sliders could have it set to 1 at all breakpoints, etc.).
Anyway, a conversation for another day
I think Misho does not spoke from a so known “slider” as more of really a “moving background”. So you can only set different background-images and the time these images will change. No slides control or anything else.
@ERES, yes that was my particular idea, but I am also looking forward to the Slider element.
I have discussed it a lot in the previous Beta with Themeco and the community. While it can quickly become a liability and a problem, it still has many great uses, especially for the Mobile UX. I am looking forward to it.
Right, and it would be much easier to dial in the controls and content if we had responsive styling first. Sliders tend to have very targeted/precise content and you will probably want to be able to make adjustments like font sizes, margin, padding, etc. on a pre breakpoint level.
I see what you mean. So in this case you would upload a list of images that are already similar in size and it would simply fade between them? I can see that being treated differently than the V2 slider/carousel request.
@alexander, yes. That would allow a background similar to what AirBnB sometimes has. The content stays the same, so the standard slider issue is not present. However the background is changing which is attractive to see. Best of both worlds. The best way to change is a slow, non-intrusive cross-fade.
I have actually split-tested this kind of Homepage Hero image. The message was about social proof, and the control had a static image, while the variation had this kind of slider. The results were unexpected: the variation won by a large margin.
It is still the responsibility of the designer to make it right, but having such native option would be really nice.
Sounds great! Great to hear some real world examples of it making a difference. Agreed on the cross-fade. That would be easy to with a simple transition on the opacity.
Added bonus would be some kind of a lazy-load queue.
If there are three or more images (over three is too many imo), then the third image onwards would not load until the first image finishes displaying. Once the full cycle is reached, all images are loaded and the image swapping continues in the loop.
Good point. On load all images except the first we could have loading="lazy" and when the javascript initializes it could make sure the image on deck (would be the second one right away) has the attribute removed.
before I forget… I think this thread is a good place to mention this, for a future reference:
For the future Slider element, i think it would be great if it also had an option to read the ACF gallery field's Image Array, or at least the IDs, so it can display images added through this ACF filed.
In practice, we would add the Slider element and set the source as ACF gallery. Once that is set, we can style it, but we cannot add any images manually. Maybe we can only add the fallback image that is shown in case the Gallery filed is not filled. Once the gallery field is filled, the slider starts to show them normally, according to the display settings. It would basically work as a Looper. The subsequent slider are grayed or not addable, and the elements on the top, if added, can be populated dynamically from Media library fields.
If the source is set to default, then we can add each of the slides manually.
If I remember correctly, the Slider element will be a sliding container, and we will be able to add any other element over each slide. This is great. I think we should then also be able to call dynamically all the possible fields from Media images. Namely the Title, Caption and the Description - for each of the slide separately.
This would open up so much possibilities and also remove the complexity from the ACF gallery field, which is not trivial to output.
Thanks! Noted. I’d have to think about that one a bit. Right now the lifecycle of Loopers is per element. This would introduce potentially setting up a new looper within an element that is being rendered. I’m not sure at the moment how that might work lots of really interesting possibilities if that was something we could do.