Blog – Sage Health Store These cards have a clickable parent, so the link from the title goes to the nearest parent. However, when I want to add pseudo classes (when hovering the card wrapper, I want to animate the image) the image becomes unclickable.
Does anyone have any idea what causes this? I’m not sure if it’s a Bricks thing, a CSS conflict, or an ACSS thing. Help would be appreciated! Tnx
Not exactly sure how you’ve built this… but my ‘method’ would be to make the archive-card_main_wrapper clickable (change from div to <a> tag and set dynamic link {post_title}). Then the whole card is a link (but don’t put links inside links, so unlink the title). You don’t need the after psuedo element or absolute positioning.
This should leave you free to add a pseudo (also not needed though). Or just add a :hover effect to the image for animating on hover.
So, there’s a conflict now? It’s a standard ACSS class, so I’d reckon it would not cause any issues. Making the whole card a link is not optimal far as accessibility goes, no? This should work around that from what I understand.
Would it help if I re-added the error? The main thing here, why I added a pseudo-class, is that I would like to have the image animate even if I hover over other parts of the card.
As for how I’ve made it: A Better Way to Create Blog Archive Templates in Bricks Builder - YouTube hope this clears it up a bit.
Not a conflict. Just different methods. I make the whole wrapper clickable and add aria labels for accessibility (which can be dynamic).
Then if I want an image effect, I can add: .my_wrapper:hover img { css stuff }
I’ve never used this absolute psuedo element idea… and couldn’t say if it’s better. I just stab at things until they work 
My way and your are very different. But I suspect that the css would still work without a psuedo… so maybe just use that?
.archive-card__main_wrapper:hover img { css effect }
Ok, I will take a look. Not sure how the current method using works exactly, to be honest. Was trying to use best practices.
But how would you solve - for instance - adding clickable categories when making the whole card a link? Can’t have links within an overarching link, no?
No, you can’t. For that I’m not sure either of these approaches work. If I need elements within elements, then I make separate parts, clickable image, clickable title, clickable categories.
But I’m with you, I can’t say my way is right… semantic, accessible, minimal, best practice etc. seems to change as fast as i can learn what was right last year!
This pseudo idea may be great, but I’m a very simple man… I want absolutely as little complexity on my page as I can, for maintainability. I will look at it tho… always interested in new approaches.
Now you’ve sent me on a hunt! Because you’re right, making the whole thing clickable isn’t best… but here’s Kevin telling you how to make the other bits clickable… as ever he takes 20minutes to tell you, but at least he tells you
Hope that helps.
Tnx, well, I added a class “clickable-parent” in ACSS. That is all I did, it makes the nearest relative element to the links clickable as if it is the link. Which is fine. But is causes pseudo-elements to not work properly - or I am doing it wrong.
It’s all in the YouTube link I sent you before.
I suggest you follow Kevin’s video, because he created ACSS. He shows how to do all that you’re doing.
clickacble-parent is only css… it doesn’t make the parent clickable… it makes the element itself the full size of the wrapper and clickable.
for example:
<my card>
<card img>
<card body>
<title wrap>
<card title>
</title wrap>
<card foot>
‘Title wrap’ IS THE PARENT - it is this element (not the title itself) you add the link to, and this element you add clickable-parent (it is the parent and clickable, not it makes the parent clickable) to. It then becomes absolute positioned and takes the whole size of ‘my card’.
Then make My Card position:relative… No need for pseudo anything. So it’s different to your original video, but for me much better and easier to control.
Then if you want links, make then relative position too. If they appear first in the DOM tree - you’ll need to use z-index as well to bring them forward and make them clickable. OR use order: -1; (or -2 etc.) to put categories LATER in the dom, but still appear first on the page - so they are clickable.
Can you say in a few words which step I did not complete correctly? Because the above is not clear to me tbh. The clickable-parent class should take care of that.
Also if I want to control the image by virtue of another element, I’ll always need a pseudo-class if I want to use CSS, no? i cannot say, hover title > change the opacity of a certain image, without it, to my knowledge.
Just watch the video.
Since the image is after the title in the html you can use what I showed earlier.
Yes, but the whole point was, this removes the clickability of set image. Let me get back to you later today, I’m in the gym and it’s deadlift day so need some focus here for a bit 
. Appreciate the time though
Apologies for running us round in circles. I’ve now created this layout as per KGs video. If it’s just vanilla it works and the image is clickable. BUT
If you add a semantic tag to the image (e.g HTML tag = picture) - bricks has some default css that breaks the link… because it sets the image position as relative:
This would seem to disable us from using best-practice… so maybe can be considered a bug? I have no idea why it would think it necessary to position something just because of a tag? But position relative raises the image above the absolute div of our link.
edit Temp fix is to go to LAYOUT and set position to static… also width if needed as this is changed to auto by bricks css. I’ve raised a bug report as this seems like it shouldn’t be necessary.
No apologies are needed. If the whole web-thingy community would have conversations like this, a lot of people would be a lot smarter.
Truth be told, my fitness session turned into me going to a local (branding not web) client. And a coffee turned into dinner and a few bottles of red wine (in my fitness outfit) Bottomline, I will take a look at this tomorrow, let’s get to the bottom of this (if you haven’t already) and so far it’s been constructive. Tnx so far! Appreciated.
You are… a legend. Thanks. I got it to work by z-index:10 on the link. But the pointer-events, allows us to have a position:relative - inside the link that is a separate link (for category links or whatnot) - and not have to z-index that too…
Wow, tnx. I will try asap!
If images on parent container get unclickable, raise their z-index against the created pseudo-class.