is there a reason why the backdrop-filter creates a pseudo element? The problem with it is that a border radius with overflow hidden will be ignored while it works fine when the backdrop filter gets applied to the div itself (in my case this div: div-c47a15d).
In CSS, there’s no background-filter property.
So when you need to filter the background of an element, you use an overlay with backdrop-filter instead, so that what is behind the overlay (the background) is filtered.
NOTE: You can’t directly use filter on the element since content would be filtered as well, not only the background.
In your case, using a backdrop-filter on a ::before or on the div itself is the same, since what you want to filter is behind the div anyway, so behind the div itself and behind the ::before.
The only difference is indeed the border radius, so you need CSS to border-radius the ::before OR to set the backdrop-filter on the div directly (and remove the property in UI), which would be healthier.
This is exactly what I did now. I expected this to happen anyway and was confused when I realized that the blur was applied to a pseudo element. But yeah – I see why the ::before solution is indeed useful
Sorry to revive this, but I’m facing a similar issue with the real backdrop-filter property, be it with Cwicly or directly in CSS.
I wanted to use a glass effect on a card nested item to blur the card background, along with the trick to expand an inner link to the whole card, for accessibility purpose (using a link on the whole card adds a lot of garbage to the screen reader).
So my setup is this:
- CARD <div relative bg-image>
-- CONTENT <div backdrop-filter>
--- TITLE <h3>
--- bla bla bla <p>
--- LINK <a before: absolute inset-0>
If I remove the backdrop-filter, everything is OK, the link ::before expands to the first relative container which is the card.
So, how would you do this without moving the link outside the content box or creating other absolute divs or changing the structure (to keep things clear and simple) and without positioning the content box to relative?
This is how I do it, as it’s completely independent of anything I do inside a card or any other element:
Unfortunately, the method you are using brings you sooner or later in trouble, as you have no real freedom in what you do. You’ll encounter more incompatibilities over time, I’m sure.
Even if there’s a workaround for this specific case (didn’t check), I’m not recommending it in favor of a unified process without any potential hurdles.
So then you just use an empty content for the link and title or arial-label attributes?
Is it OK to have an empty <a></a>?
EDIT: Tested and it’s actually working perfectly and indeed it gives total freedom to the rest
And no need for z-index if you put the link after the content, in simple cases
Exactly
Just treat this element like your link/CTA.
Absolutely!
You aren’t even dependent on the existence of a CTA inside an element/card.
So this can be used universally for everything and without any dependencies, especially the position property, which in most cases is the culprit.
Edit:
Great to hear
True, I think it’s more of a thing how you organize your structure and of course, as you mentioned, how complex the element is. I agree that for simple elements this is fine.
But as this is not always the case, I like to have the link always on top, rather than a block that’s always on the bottom (skipping a block intuitively might make more sense than subtract it from the end of structure).
And as it’s part of a global class in my case, this additional rule won’t hurt either.
Can you elaborate?
Before getting too hacky (if that’s the case), keep in mind that the ::after pseudo element is still available to use without any styles attached yet (I assume). So that should work.
That’s why I was thinking using a paragraph block as the link, so that the paragraph content is used to explicit the link (instead of title or aria-label attribute) but with opacity: 0, since I don’t want it to be displayed.
This is actually working well, a bit tricky, I admit, but the absolute positioned link is already kind of a hack, so…