This suffers from the problem of only blurring using the pixels immediately behind the surface, as demonstrated well in https://www.joshwcomeau.com/css/backdrop-filter/#the-issue. That and the discussion in https://news.ycombinator.com/item?id=42302907 are good reading. If the backdrop is going to move underneath, this is fairly important; if it will be static, it’s not normally important.

▲

kris-kay 2 days ago | parent | next [-]

I did read Josh's great article and had a go at implementing the tutorials. Unfortunately, I ran into some issues with the border-radius via SVG mask bit. It worked great on a hardcoded element, but I still need to figure out how to make it work across a whole component library where the border-radius changes based on the user's branding and container-queries.

▲

account42 14 hours ago | parent | prev | next [-]

I don't think either version is really more correct than the other. The default approximates an object that is directly behind the frosted glass while the tweaked version simulates an object that is much further away.

For me the tweaked version is much more distracting and looks more wrong due to conflicting depth signals.

▲

andrewmcwatters 2 days ago | parent | prev [-]

Josh’s solution also intuitively appears wrong to me because it seems to assume that nearby elements are emissive, and I can’t agree with that as a standard physical property of “materials” on the web.

I instead assume that materials are by default more similar to paper.

▲

chrismorgan 2 days ago | parent | next [-]

The backdrop blur is unrelated to the surface properties of the elements underneath: it’s about the frosted glass refracting light, and some of that light it refracts comes from beyond its bounding box, which a naive backdrop-blur won’t observe.

▲

andrewmcwatters a day ago | parent [-]

Frosted glass doesn’t pass through light of objects that are simply near by it. It doesn’t make physical sense. I understand the defect, but neither does this solution correctly fix the problem.

Note the circle before it intersects with the rect, without accounting for pixels beyond the bounds, the blur is incorrect because the kernel doesn’t take into effect the circle.

Note the blur after extending the kernel beyond the visible bounds. While the blur is correct, the albedo of the shape passing through the rect no longer makes sense. The circle is not emissive, and yet despite this, you see the blur of the circle behind the rectangle without it intersecting in a full-bright environment. Why can we assume the environment is full-bright? Because there is no lighting. Only albedo.

Neither are correct.

▲

chrismorgan 9 hours ago | parent [-]

I have an inking of what you’re getting at now. I want to try modelling it with full ray tracing now (in the absence of a piece of actual frosted glass!), to convince myself if you’re right (I’m not sure one way or the other), but sadly I doubt I’ll get to it any time soon.

	▲	andrewmcwatters 3 hours ago \| parent [-]
		I used physical samples of pebbled glass, curved glass, and clear glass. You can get the same effect using curved glass because of how natural light bounces off of the surface of the subject object and onto the glass, but you don't get this pronounced of effect with a flat panel of glass, frosted or not. It's too exaggerated for, say, a kernel of 32px.

▲

nothrabannosir 2 days ago | parent | prev [-]

That article covers a bug in implementations of blurring in browsers. It shows how when a 200px red circle is fully covered by a blur with radius 16px, today you will see a 232px sized blurred circle. But when the circle is shifted down from under the blur, so there is one pixel of space separating the two, you would still expect to see 15 px of blurred red circle. Instead it goes 18, 17, 16, 0, 0, for every successive frame. That’s a bug.

	▲	chrismorgan a day ago \| parent \| next [-]
		It’s not an implementation bug, it’s a deliberate design limitation in the name of performance. (There are quite a few practical limitations on backdrops in the name of performance.) It’s not impossible that this will be adjusted in the future in some way, like how browsers quite some years ago shifted to premultiplying colours so that a gradient from white to transparent doesn’t go through semitransparent grey, but browsers are acting according to spec.
	▲	andrewmcwatters a day ago \| parent \| prev [-]
		It’s an implementation limit of a limited backing layer size. So no, it’s not a bug. But neither solution correctly blurs objects that insect with the layer.