Hi!
I tried to define a mobile background image in a Media query:
background-image: url({{dc:acf:post_field field="hero_image_mobile"}}) !important;
However, that doesn’t work.
When I put in the actual URL which is the exact same one as the output of this dynamic content, then it works.
I tested the output in a text element, and it looks as it should: just a plain URL.
Thanks!
Thanks @Misho, there might be something going on with Element CSS and Dynamic Content in beta4. We’ve seen some inconsistencies in some of our own designs but haven’t checked into it yet.
One thing you could try in the meantime is wrapping the DC in a var like this:
background-image: url(var('{{dc:acf:post_field field="hero_image_mobile"}}')) !important;
In either case, let me know if you can find what is actually outputting on the front end. It’s probably outputting some broken form of CSS, and seeing that could contribute to the solution here. If you can’t find it no worries, this one is on my list of things to investigate already. Thank you!
I forgot to reply here, sorry!
I am now experimenting with this and still cannot get it working.
I am trying to call an alternative background image for a Div element, from CSS.
The standard background image is being set normally using the standard image settings. However, I want to be able to override that image if needed, using parameters.
This is what I tried:
background-image: url(var('{{dc:p:bg-image-alt}}')) !important;
I tried this as well:
background-image: url({{dc:p:bg-image-alt}}) !important;
Neither of the two seems to be working.
When I try to output {{dc:p:bg-image-alt}} into plain text, it returns this: 149:full.
Is there a proper way to call a background image dynamically from custom CSS?
Thank you!
That’s a great question. To turn 149:full into an image path you’ll need to use cs_resolve_image_source in general. I ran into this issue in my own custom plugin and I do really wish it preprocessed before sending image data, I’m not entirely sure we can do that though.
To fix your issue, I’m going to add a type='image' which will call the above function for you . It’s really quick on my end as well so expect it in 6.1.3 You would then use {{dc:p:bg-image-alt type="image"}} to expand to a full url path.
This sorta ties into why I’d love to integrate twig or a more robust templating engine. Because then I could just tell you do something like {{dc:p:bg-image-alt | cs_resolve_image_source }}. Someday Misho. Thanks for bringing this up!
Appreciate that Misho.
You might have already noticed that Element CSS gets broken up into variables. This won’t work with the background-image because it needs the url() part. I’ve created a new constant to bypass the CSS variable creation and it’ll just template your element CSS like how you would expect dynamic content to do. Let me know if you have questions there. Coming out Monday.
define("CS_TSS_IGNORE_VARIABLE_CREATION", true);
Thanks @charlie !
If I understood you well, that would mean that we will use the regular one, like this?
background-image: url({{dc:p:bg-image-alt}}) !important;
Thanks!
(looking forward to this one, it will open up so much possibilities and improve on what Pro can do!)
It would be the below. You’ll still need type='image', and the constant if your using url(). I have feeling we’ll be making the constant the default in the future, but I’ll keep the same for now and see how many issues we get with creating CSS variables in custom element CSS.
background-image: url({{dc:p:bg-image-alt type='image'}}) !important;
Hi @charlie!
It works, fantastic!
I added the constant to the child theme’s functions.php. I hope that’s where it was supposed to go. 
Hi @charlie!
Unfortunately I just discovered that the constant is preventing the "isVar" : true from working properly. When the constant is active, elements stop being responsive. As soon as I remove the constant, they start working again.
(Tested on Min. Height of the Div element).
Thanks!
Ah that’s a shame. Well I’ll have to see about figuring out another solution for this without losing parameter breakpoints.
Great! I’m sure you’ll get it!
This solves one of the last remaining limitations of parameters, especially when it comes to responsive image controls. Can’t wait for it to be fully operational.