[csswg-drafts] Progressive blur for `blur()` (#13285)

damian-dp has just created a new issue for https://github.com/w3c/csswg-drafts:

== Progressive blur for `blur()` ==
CSS `blur()` and `backdrop-filter: blur()` are currently uniform across an element. Modern UI frequently needs a progressive (gradient) blur: blur that ramps from 0 → N in a direction (e.g. toolbar/footer scrims, “fade-to-blur” overlays, edge treatments).

This issue proposes a minimal, backwards-compatible MVP by extending the existing `blur()` filter function to accept a from/to pair plus an optional direction, reusing `linear-gradient()`-style direction syntax.

### Primary use cases

1) **Backdrop blur scrims** (common on toolbars / bottom sheets): blur increases toward one edge to improve legibility without fully obscuring content.
2) **Edge fade effects**: progressively blur content toward a boundary (e.g. behind a floating header) rather than uniformly blurring the whole element.
3) **Design parity with native UI**: progressive blur is a standard primitive in modern UI design tools and OS UI patterns; web currently requires heavy workarounds (layering + masks) that don’t actually vary blur radius.

<br>

<img src="https://github.com/user-attachments/assets/78f5cc53-60b1-482b-bec0-7ea4df55991e" height="280" alt="Image 1">
<img src="https://github.com/user-attachments/assets/f57b042a-69c8-4188-b645-def2ce5d29b5" height="280" alt="Image 2">

---

### Proposed API (MVP): extend `blur()` to allow a directional ramp

Allow `blur()` to take a *from/to* pair plus an optional direction, analogous to `linear-gradient()` direction syntax:

```css
/* existing */
filter: blur(<length>);

/* proposed (progressive blur) */
filter: blur(<from-length> <to-length> [[to <side-or-corner>] | <angle>]);

/* also for backdrop blur */
backdrop-filter: blur(<from-length> <to-length> [[to <side-or-corner>] | <angle>]);
```

#### Example:

```css
.scrim {
  backdrop-filter: blur(0px 24px to bottom);
}
```

#### Semantics
- Blur radius varies linearly from `<from-length>` to `<to-length>` along the specified direction.
- Default direction when omitted: to bottom.
- With a single `<length>`, behaviour is unchanged (uniform blur).
- The intent is to follow the existing coordinate space / region model that `blur()` and `backdrop-filter: blur()` already use, with the smallest possible spec surface area beyond new arguments.

#### Non-goals for MVP
- Radial/zoom blur
- Motion/velocity-coupled blur
- Custom start-point offsets / multiple stops / nonlinear ramps
- Mask-driven blur maps

Those could be explored later, but this issue is intentionally scoped to the simplest, most common UI need: “blur gradient in a direction”.

### Why extend `blur()` instead of adding a new property?
- Keeps the mental model consistent: this is still a filter effect.
- Works everywhere filter functions already apply (filter and backdrop-filter).
- Minimises new concepts and avoids introducing a parallel syntax surface.

### Open questions
1. Should this live in Filter Effects (FXTF) as an extension to the `blur()` function grammar?
2. Any known implementation/performance constraints for a spatially varying blur radius that should shape the MVP?
3. Should we also consider a logical-direction form (e.g. to block-end) or stick to the existing physical to top/right/bottom/left + angle forms for MVP?

---

**Related**
- Broader “Motion Blur Effects” discussion: https://github.com/w3c/csswg-drafts/issues/11134

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13285 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 1 January 2026 09:56:01 UTC