[chrismorgan]

I don’t like the `height: 200%`: you might as well be specific about how much extra you need, because an extra 100% might be a lot more than you need, or not enough.

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.

[8n4vidtmkvmk]

All this time I thought a 16px gaussian blur meant it faded to 0 at 16px. That explains why I always seem to need to add some extra padding! I never thought to question it! Wow! I can use this right away to fix some stuff, thanks for sharing!

[chrismorgan]

Thanks for the response! It’s always nice to know when some incidental thing you remark on has helped someone. Thinking back, I suppose I struggled with understanding the SVG <feGaussianBlur stdDev> parameter when messing around with complicated filters in Inkscape a few years back, for much the same reasons. And I didn’t actually know the ¾√2π until today, I just knew that a factor of 2 was a little more than enough. I’m glad for the note being attached to the spec, it’s a great note.

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.

[joshwcomeau]

Author here — yeah, so my goal with 200% was to make the code as comprehensible as possible. My actual glassy header does something quite similar to what you’re suggesting, but that also raises the bar quite a bit for how much CSS you need to know in order to understand this post.

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.

[vinnymac]

Your effort to make these posts consumable by the masses doesn’t go unnoticed. It’s clear you put a great deal of work into them, and the quality you achieve raises the bar in many ways for what to expect when learning about the web. If only all educational materials on MDN could reach these heights.

[chrismorgan]

Honestly, I feel that `bottom: -32px` and `calc(100% - 32px)` might be easier to understand than `height: 200%` and `50%`. (Yeah, for early teaching I might step back from using `inset`.) It does require the one extra concept of calc(), but it’s exact and feels slightly more easily explicable than how 50% of 200% is back to 100%. The fact that the number 32 would be present in both makes it easier to track, whereas the fact that 200% and 50% are inverses is pretty easily overlooked.