the default for attributes is the element root, which is in case of the image element the figure tag.
But you’re right that it makes more sense to add the attributes directly to the image instead to the figure.
Short update: it is a bit more complicated than expected. For example, as soon as we want to place a gradient/overlay over the image, we need a wrapper, because pseudo-elements do not work with self-closing tags, as the img is. The caption also needs a wrapper because it is positioned absolutely.
In every other case, the image element will output a pure img-tag.
However, it is of course possible to put the pure img in a container and change the container tag to figure or picture if needed. This way you can distribute the attributes as you wish.
Do you want to be able to overlay your images directly or is it sufficient indirectly via a container?
Can you think of any other settings for the image that requires a wrapper?
If the wrapper is there: where should the attribute go? Wrapper or img (either/or)?
I am a bit confused about this discussion and its options.
I have a seperate ticket open, because an image in the footer does not show the overlay color, so from my perspective, this falls into the same cause. Without a container „around“ the image, I can not put gradient etc. on the image. And until 1.3.7 a kind of container/wrappper around the image was there that solved this solution.
So, if I understand this discussion, I would suggest:
Deliver an IMG as an element without an wrapper, but if there are addintional settings for the IMG are choosen through the editor, then the IMG gets an additional wrapper around it to show the things like gradients etc.
Indirectly via container. Don’t bloat the img tag with wrapper when not needed since it can live without.
Any before/after (overlay or other decorative stuff like icons),
figure with caption,
picture with srcset or webp,
fixed ratio (absolute img inside a div with fixed padding to simulate image ratio, since CSS ratio is still not well supported)
No wrapper. Add it manually and set attributes on it.
Automatically adding a wrapper if some options are set seems odd and confusing.
I personnally think the better is the closest to HTML, lowest level possible, so that we can combine anything later on, like real code.
Maybe add figure/picture/image with wrapper as complex elements, but separate from image element alone?
When we need any overlay, we can add the container ourselves. Please remain clean code. When we use an image element, leave it as it is as <img src="image link" title="" others=""> Dont’ wrap the image element with an extra wrapper. So we have the freedom to any element in the builder.
One of the main objectives of this 1.4 release is definitely to further remove any bloat. At the same time we need to maintain a consistant + straightforward editing experience throughout all available Bricks elements for all kinds of experience/skill levels.
Here are my thoughts in form of a video about how the “Image” element in 1.4 could work using a conditional figure tag. Let me know in the comments below what you think about this, and which settings require a figure “wrapper” (Image caption, Image overlay, Gradient/Overlay settings, ???).
Thanks, @thomas !
If an extra wrapper is necessary for some elements, can you please make it happen for us to add any classes to the outer wrapper and img tag (we can add any classes to any wrappers of the element)? Zion Builder does this pretty good as they allow us to add any classes to the parent wrapper and all the inner wrappers and elements.
So we can have complete control over all the elements.
Hi @thomas, nice to see you again!
(I’m back on testing Bricks.)
I like your idea of automatizing figure tag when needed, even if as a dev, I’m not fond of these shortcuts
But there’s one drawback left: how do you handle id and classes?
In your video they are set to either img or figure.
But in our stylesheets it could be a mess, or if using utility classes from CSS frameworks…
Also, what if we need to use picture tag instead of figure?
@thomas ’ solution is spot on - no image wrapper unless required by one of the builder options that needs it.
As others have mentioned we would like to be able to change the wrapper tag to whatever we want - - which, if this concept is carried through all of the way, then how about a builder setting:
“figure” tag is default image wrapper unless we choose to enter a custom tag.
I am undecided between this. What I like is that for normal use we will use this img element and it will work perfectly fine. If we will not use overlay or caption, the HTML will be clean. But as soon as we add one of those, the image will get automatically wrapped in figure, so this is good.
But the “problem” I see is that as a dev, I will never know exactly how the element will render. Of course, I will know if I will look at the frontend I will see. Now imagine this, I will add some custom style to the image element and make it work, but after that I decided to add some overlay to the image. The class changes from image to figure element and it is possible that somthing will not work properly.This is my main concern.
Otherwise, don’t get me wrong, I like this, because it keeps the builder simple and most of the times it will just work.
In terms of predictability (when using custom CSS) it seems better to always render an image wrapper. Which is why we originally decided on this approach. We can provide a HTML tag setting to set it to figure, picture, etc. That’s not a problem.
At the same time users want to optimise their markup as much as possible. Using dozens of images on a page, all with an unnecessary wrapper definitely adds to the bloat. And a good argument for the conditional wrapper.
Satisfying everyone & every possible use case, seems not possible here. In the end, it’s a compromise, which should favor how the Image element is used by most users & most of the time.
I think in terms of possible custom CSS issues we have enough smart users here to help find a solution if the need arises
I’ll proceed with the conditional Image wrapper, for which I’ll add a HTML tag control too. Once 1.4 is out, and everyone had some time to use the new Image solution & markup, let’s continue the discussion here.
Nothing is set in stone, and we’ll always try to find the best possible solution