I just noticed that some figure elements have an additional .tag class and that is adding some inline CSS::
where(.brxe-image).tag {
display: inline-block;
height: fit-content;
position: relative;
width: auto;
}
Why is that?
It means I can’t have images that are not position:relative…
This part isn’t true. As soon as you change the position on the image element, it will override the default CSS.
but not if I have a class for my figure elements
The inline css is over-riding my external
The thing is, why is Bricks adding .tag?
If it helps, the .tag class is overriding styles set on a class on the image when bricks is set to external css
When it is set to inline CSS the class on the image over-rides the .tag
Is this a known bug?
I can confirm Tony’s comments here - this has happened on a website I’ve been working on
Probably best to post a bug report, with exact steps on how to replicate the issue. Then the Bricks team will be able to confirm if it’s a bug or intended. (it may be that the position relative is needed for something in the image element, similar to how it’s needed when adding a color overlay to the image)
I can see the tag class on the figure when captions are enabled, but I can’t replicate not being able to override it. Whether i set the position with a class or ID in Bricks, it overrides the default styles, so unfortunately, i can’t really help much there. if you’re adding the CSS outside of Bricks somewhere, then it may be the loading order that is the issue, where you need to add your CSS in later.
Having the same issue on 1.9.2 Did anyone find a fix for this?
I’m also running into this issue. The only fix I am able to come up with right now is to manually override the .tag class on every image element which I really hate doing.
If the class is indeed supposed to be applied when images have caption enabled, then I would consider this a bug because the .tag class remains even with caption type > no caption.
It’s just that an additional “none class Tag” setting is needed for the widget.
Until I saw it here, I didn’t even know about it and I didn’t have any inconveniences.
Any idea what this tag thing is about? I updated Bricks, and it’s broken loads of my styles now by overriding them with the .tag? (attached image).
I’ve got around it by making the class more specific, but any ideas why that’s just happening now, and why tag is only on the first image element?
did anyone find a solution or report it as a bug? I face the same issue on a client site.
I’m seeing this issue as well whereby a tag class is causing my logo to change size depending on which single page template I’m using.
At left is a page using a single page template that also has a hero section applied via condition (terms, happy files folder taxonomy).
At right is the home page which is only bricks and does not have the same hero section applied.
Why would the styles for the logo in the header load differently if they are not part of the single page template?
Still no answer to this? I’m having the same issue in August 2024.
Same problem here with the .tag. Need to modify almost all images through the .tag class.
Hey all, this is still not fixed. My images wrapped in figure suddenly got another class automatically applied (.tag). And for whatever reason this overrides any class level or id level styling. Have to use !important to override.
This has been happening for over a year now. Please take a deeper look into this.
Just fyi: I have integrated a short JS that removes the .tag class from every figure element on page load. This is surely not optimal, so any help is appreciated!
I concur. I have no idea what is going on with tag, but when now using any brixies.co templates, the positions are being overridden. Did anyone figure out a simple workaround? I reported a bug:
.tag on images again - wasnt happening recently, now it's back
