Backdrop-filter creates pseudo element?


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).

On the left side I use the settings above. On the right I applied the backdrop-filter via custom CSS directly to the div.

1 Like

As you can find it inside the background panel, it’s just a neat shortcut.

I think you are looking for this one (for more granular control):

1 Like

Hi @Marius,

thanks for bringing this feature request up.
What do you mean with “neat shortcut”? What is the advantage with using a pseudo element in this case?

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.


Thanks for the explanation! This makes sense.

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 :+1:

1 Like

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>

The problem is that backdrop-filter creates some kind of positioned container wrapping the element (here the content div) that prevents the link `=::before to expand to the card, because it is constrained to first positioned container.

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?

What I want:

Result WITH the backdrop-filter:

Result WITHOUT the backdrop-filter:

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.

Thanks :slight_smile:
I had the feeling it was the best way…

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 :wink:
And no need for z-index if you put the link after the content, in simple cases

1 Like

Exactly :+1:
Just treat this element like your link/CTA.

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.


Great to hear :sunglasses:

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.

1 Like

Makes totally sense, thanks :slight_smile:

1 Like

Damned, we can’t yet use components properties in attributes…
So I think an invisible link content wouldn’t hurt?

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.

Maybe an okayish workaround until

are available.

Where??? I must be missing something!
I couldn’t find how to connect a property to attribute, and saw this request: Add data attribute to Components and their properties

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…