- From: Damian via GitHub <noreply@w3.org>
- Date: Mon, 05 Jan 2026 10:05:41 +0000
- To: public-css-archive@w3.org
Thanks @SebastianZ — before debating syntax, I want to make sure we're solving the same problem.
My original issue targets true progressive blur: spatially-varying blur radius, as seen in native platform effects. At one end the kernel is 0px (sharp); at the other it's 24px (soft). The blur computation itself varies across the element.
This is distinct from blended blur: compute a uniform 24px blur, then fade between original and blurred output via a mask. That's what the current workaround produces:
```css
.scrim {
backdrop-filter: blur(24px);
mask-image: linear-gradient(transparent, black);
}
```
When you say:
> `blur()` — Affects the blur radius, interpolating between 0 and the specified value
Does this mean:
- **(A)** mask=0.5 → blur radius is 12px at that point (variable kernel)
- **(B)** mask=0.5 → 50% blend between original and 24px-blurred result (uniform kernel, blended)
These produce different visual outcomes. (A) preserves detail where blur is low; (B) hides uniform blur behind opacity.
---
If masking produces (B), we're standardising an existing workaround — cleaner syntax, but no new capability and no parity with native tooling (iOS/macOS, Figma, etc.).
I'm not attached to `linear-blur()` as syntax. If your proposal produces true variable-radius blur, we're just debating ergonomics — and generalisation may well be the better path. But if it produces blended output, it doesn't solve the problem I raised in #13285.
Could you clarify which behaviour you're proposing?
(To be clear: my focus here is specifically on the progressive blur use case. Your generalised masking approach may well have merit for other filter types — I'm not arguing against it broadly, just trying to understand whether it addresses the specific problem I raised.)
--
GitHub Notification of comment by damian-dp
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13288#issuecomment-3709761871 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 5 January 2026 10:05:42 UTC