figure replaces image wrapper in 1.4 which is good, but how do i assign a class or an attribute directly to the image tag?
cause when I add something in the builder it will be added to figure not to the img tag it self.
what do i miss here?
example: I want the hero image to load eager
cheers,
Markus
Hi Markus,
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.
We’re going to change this in 1.4 final.
Best regards,
timmse
Why forcing the figure tag in the first place?
I think most of the time we don’t need it.
(I actually only use it when I have a caption or if I need an overlay).
IMHO there should be an image element (img tag only) AND a figure element (figure tag only), so that we have the choice to use img tag alone or nest it inside a figure tag.
Or we can just use a container and change the tag to figure, since it is available (and for a legend add a text element with figcaption tag).
Let us have the ability to choose the tag when we use an image element. Just as same theory as no extra wrapper or anything else.
For the image tag, we can choose the tag for img, picture or whatever it should be.
@timmse thank you for the update.
I actually agree with @yankiara, since the img tag is not the same thing or used the same way as the figure tag or the picture tag, in an ideal world there should be a choice.
most of the times an img tag will just be fine, and yet figure and picture can come in handy in certain cases.
cheers,
markus
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.
Summarised:
Let me know what you think 
Stefan,
don’t know what others think but here my view:
no idea actually, here others might be better to answer
for example:
picture
source srcset=“image.avif” type=“image/avif”
source srcset=“image.webp” type=“image/webp”
img src=“image.jpg” alt=“A description of the image.” width=“300” height=“200” loading=“eager”
decoding=“async”
/picture
directly to the img tag
still think that you should add the choice of img only, figure or picture directly in the image element.
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.
What do you think about this @timmse ?
Hey,
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?
Agree with what yankiara said above about the other options.
I also agree with above. Try to have code output closest to HTML and maybe create new element if needed with wrapper.
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.
And, we hate bloat.
Thanks so much for all the feedback
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.
Hi.
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.
I’m not sure if this doable.
When the time we add an image element, the IMG is not wrapped by any wrappers until we choose the HTML tag or we started styling the image like adding overlay or etc.
When there is no styling apply to the image, the image remain <img tag
Need opinion.
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 