It makes me very happy that someone not only noticed this, but did something about it, and then shared it freely!
First question: how much more do you need? Per https://drafts.fxtf.org/filter-effects/#funcdef-filter-blur (via MDN blur() docs → link to spec):
> Note: A true Gaussian blur has theoretically infinite extent, but in practice all implementations use a finite-area approximation of a Gaussian blur. At the time of writing (January 2024) all major implementations use the familiar three-pass box blur approximation, which has extent: ((3 * sqrt(2 * π) / 4) * σ).
¾√2π is about 1.88; it’s generally most convenient to just double the radius instead.
So, if you’re going for a 16px blur, add 32px. (The formula would make it 30.079px; so I’d accept 30px and 31px also.)
In the first main demo with code: ditch the `height: 200%`, change the inset to `0 0 -32px 0`, and change the 50% in the mask-image linear-gradient to calc(100% - 32px). (Aside: you can also shorten the gradient definition: linear-gradient(to bottom, black calc(100% - 32px), transparent 0%).) Applying it to later things is left as an exercise to the reader.
The SVG <filter> element is interesting in this rendering size question: it lets you control the rendering area for the filter, via its x, y, width and height attributes. Their defaults are -10%, -10%, 120% and 120%, meaning 10% overdraw on each edge. Unfortunately you can’t really do height="calc(100% + 32px)" which is what you’d want for the equivalent here. Yes, you could definitely do this whole thing in SVG, using the BackgroundImage source—in fact, you can do better, because you can composite that with SourceAlpha, rather than the dodgy mask-image technique you’re limited to in HTML/CSS. Unfortunately I don’t believe any current browsers support BackgroundImage, though I think IE and Opera used to, and Inkscape does.
Although people often talk of blur radii, it might help to remember it’s a standard deviation. Take the curve in https://en.wikipedia.org/wiki/Gaussian_filter#/media/File:Ga..., and a Gaussian blur is taking so much of each pixel value, most from the closest ones, less from further away, negligible by two standard deviations away, but only asymptotic to zero; hence the “theoretically infinite extent” the spec note mentioned. But the ¾√2π thing will probably be good enough forever.
I like making things like this copy/pasteable, rather than NPM-installable, so that more experienced developers can make tweaks like the one you suggest.
Both of these posts add additional tweaks beyond `backdrop-filter: blur()` to enhance glass effects. We use different tweaks so it looks like the techniques in each of our posts is compatible. When I get around to it I’ll update my page to link to this new one.
Perhaps in a few weeks we will get the, “I’ve consolidated all the HTML glass effects on HN and this is what it looks like,” post :)
But it is unique in its own way and has many other good ideas.
A lot of UI work I do is experimenting with different ways to do things to find what’s cleanest for the specific situation.
Small note that the drag UX doesn’t appear to work on iOS.
It's great to experiment, but don't use this in projects that you intend to maintain.
Signed, someone who used to do this a lot.
Many people value creating and using products with these kinds of details, I disagree with "don't use this in projects you intend to maintain" as across-the-board advice.
I disagree. Check the changes required to the spacing/sizing. Soon you will need to adjust those values and that.is.maintenance. Multiply this by each detail and soon you have more work than you signed up for. This is usually when someone comes along and wants a rewrite because the codebase is fragile.
Backdrop-filter is... fine. Using masks, animations, and backdrop filter, and gradients, especially for fine details like edges, are just asking for trouble.
Browsers are incredibly complicated, and rendering engines have lots of edge cases, broken features, slight incompatibility issues some of which vary by hardware/os/enabled-flags.
IME, this would definitely not be worth it.
I'd rather open a bug report and hope for the best in this case.
Sure, if you are building an enterprise application, this likely doesn't make any sense.
But, if you are building something for a consumer audience. Or if you are trying to differentiate yourself by building something beautiful. Then maybe wrap these 100 lines of code in a very specific class name (.fancyGlassFrostedGlass) and call it day?
Chrome & Safari render it differently but interesting, Firefox is skipping it completely … I‘d need to look into it. Anyway, just wanted to share it :)
Firefox on Mac _may_ have a slight lag scrolling now which Chrome does not show.
Not mentioned in the article (that I saw) is that despite being a background blur it will affect all elements placed in the header, even with z-index higher than the blur, unless you mark them `position: relative;`. I added that style to my nav container.
I may add more graphics soon!
Also ran into odd colour issues in Firefox when combining it also with opacity.
A bit too "next-level" for my iPad it seems.
