Why are there .tag classes on my figure images?

[Adrien]

Why do we have to fight against the system, that’s painful…

Can’t we just have a setting that prevent Bricks from having this .tag class?

[Adrien]

Hi @Matej,

Can we have an answer on this?
It’s not possible for us to always have to add a more specific CSS selector to fight the width: auto; coming from Bricks .tag class…

Thank you for considering a fix for that.

[Matej]

@Matej

You can try to switch to inline CSS styles if it will solve it or you will have to create a bit more specific selector.

Have you tried that, @Adrien? Did the “inline” styles solves the issue for you?

If yes, then it’s the same issue as I’ve linked above, and we have an internal task already created.

Please let me know.
Matej

[jakasspeech2]

@milkrow

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. https://www.shopsy.si/

Why would the styles for the logo in the header load differently if they are not part of the single page template?

The different template styles may be causing this issue. The hero section might be applying CSS that’s affecting the logo’s size in the single page template.

[webmonkey]

I’m having this same issue when switching from internal to external stylesheets. I would prefer to use external, of course.

[timmse]

It should be solved by using cascade layers @webmonkey

1.12.4: Bricks » Settings » Performance » Cascade Layer
2.0-alpha: Nothing to enable, as it’s the new default

[webmonkey]

Yep, that fixed it. Much appreciated.

[mr.matt.eastwood]

Hey guys, I ranted about this on Facebook and Maxime led me here.

I’m still unsure about the reasoning behind adding this class and its CSS “behind the user’s back” (for lack of a better term) and not giving us access to it. It causes us to lose time questioning our sanity and rifling through the DOM to find what’s breaking our layouts.

Case in point: @layers or not, the image in this layout won’t stretch because of height: max-content; on the .tag class.

Bricks: .tag class interferes with align-items: stretch;

(Link from the video: dsadsasda » Pflegeteam Lampe)

Well-intentioned as the CSS may be, I’ll go out on a limb and say it interferes with our work.

I wrote some counter-CSS and it’s all good now, but the fact I had to do this reminds me of my Beaver Builder days and triggers some old traumas

[emmanuelson]

Hey @mr.matt.eastwood the video is not playing for me but if you set align-items: stretch on the container, it should stretch