[svgwg] Filter Effects: define interoperable backdrop displacement/refraction for “liquid glass” UI (#1142)

Jofdt has just created a new issue for https://github.com/w3c/svgwg:

== Filter Effects: define interoperable backdrop displacement/refraction for “liquid glass” UI ==
Modern UI design is moving toward “liquid glass” / refractive glass surfaces: translucent interface elements that blur, brighten, and physically bend the pixels behind them. Apple can do this natively through its OS compositor, but there is currently no reliable, interoperable way for web authors to create the equivalent effect using SVG/CSS filters over live DOM content.
SVG already has most of the mathematical machinery needed for this. In particular, <feDisplacementMap> can spatially displace an input image using the red/green channels of a second image. Authors can generate displacement maps from height fields, surface normals, or Snell’s-law-inspired refraction models, then feed those maps into <feDisplacementMap>.
However, the web platform currently lacks a reliable way to apply this kind of displacement to the live backdrop behind an element.
The result is that authors attempting “liquid glass” effects are forced into fragile workarounds:
1. backdrop-filter: url(#svg-filter) — ideal in concept, but not interoperable for SVG filters such as <feDisplacementMap>.
2. filter: url(#svg-filter) on a cloned copy of the content — works in narrow cases, but requires duplicating DOM or media, causes scroll desynchronization, accessibility hazards, and performance problems.
3. WebGL/WebGPU — can do the math, but cannot sample arbitrary DOM/backdrop pixels for security reasons, so authors must recreate the page inside a canvas/texture.
4. Plain backdrop-filter: blur(...) — interoperable and performant, but cannot create real refractive displacement.
This issue requests discussion of a standard, secure, compositor-friendly way to support displacement/refraction filters over backdrop pixels.
Use case
A common desired authoring pattern is:
.glass {
  position: fixed;
  inset-block-start: 0;
  inline-size: 100%;
  block-size: 80px;
  background: rgb(255 255 255 / 0.15);
  backdrop-filter: url(#refractive-glass-filter) blur(18px) saturate(140%);
}
<svg width="0" height="0" aria-hidden="true">
  <filter id="refractive-glass-filter">
    <feImage
      result="map"
      href="generated-displacement-map.png"
      preserveAspectRatio="none" />
    <feDisplacementMap
      in="BackdropGraphic"
      in2="map"
      scale="40"
      xChannelSelector="R"
      yChannelSelector="G" />
  </filter>
</svg>
The exact name BackdropGraphic is just illustrative. The missing concept is a standard filter input representing the pixels painted behind the filtered element, in the element/lens coordinate space, usable by displacement primitives.
Why existing SVG/CSS mechanisms are insufficient
1. 
<feDisplacementMap>
is suitable, but only for available inputs
<feDisplacementMap> already exposes a useful low-level primitive:
<feDisplacementMap
  in="SourceGraphic"
  in2="map"
  scale="40"
  xChannelSelector="R"
  yChannelSelector="G" />
Authors can use this to approximate refraction. For example:
* Generate a height field for a rounded glass lens.
* Compute approximate surface normals.
* Use a Snell’s-law-inspired model to derive x/y offsets.
* Encode x displacement into red and y displacement into green.
* Use neutral 128,128 as no displacement.
* Feed the map into <feDisplacementMap>.
This works for distorting the element’s own pixels (SourceGraphic), but not for distorting the live pixels behind the element.
2. 
backdrop-filter: url(#svg-filter)
is the natural authoring model, but not reliable
The CSS backdrop-filter property is exactly the conceptual fit: it applies graphical effects to pixels behind an element. Its syntax allows SVG filters by URL.
But in practice, SVG filters inside backdrop-filter are not interoperable. A known WebKit issue reports that backdrop-filter: url(#some-svg-filter) does not work with SVG filters such as <feDisplacementMap>. In author testing, Chromium may render some cases, while Safari/WebKit does not.
This prevents authors from using the obvious standards-based syntax for refractive backdrop effects.
3. Cloning DOM/content into the glass element is not a good standard workaround
A common workaround is:
* Duplicate the visual content behind the glass.
* Counter-position that copy inside the lens.
* * Apply filter: url(#svg-filter) to the copy/lens.
This can prove that <feDisplacementMap> works as a primitive, but it is not a robust web authoring model.
Problems include:
* Main-thread JavaScript synchronization with compositor-thread scrolling.
* Visible lag/jitter while the real page scrolls independently of the cloned copy.
* Accessibility issues if arbitrary DOM is deep-cloned, including duplicate IDs, broken ARIA references, hidden focusable elements, and keyboard traps.
* Performance issues from cloning, measuring, and transforming large subtrees.
* Need for complex source selection logic on dynamic pages.
* Poor behavior with lazy-loaded images, sticky elements, drawers, modals, transformed elements, and changing layout.
A standards solution should avoid requiring authors to clone live DOM to get backdrop refraction.
4. Canvas/WebGL/WebGPU cannot sample arbitrary DOM/backdrop pixels
GPU shaders can produce beautiful refraction, but web security correctly prevents arbitrary DOM/backdrop pixels from being sampled into a canvas/texture. Workarounds such as DOM screenshots or recreating the page inside WebGL are too heavy and brittle for ordinary web UI.
The browser compositor already has the pixels required to compute a backdrop filter. Authors need a safe, declarative way to apply displacement/refraction to those pixels without exposing them to JavaScript readback.
Current practical author approaches
Today, authors attempting liquid glass generally choose among these:
A. Native CSS glass
.glass {
  background: rgb(255 255 255 / 0.18);
  backdrop-filter: blur(20px) saturate(140%);
}
This is performant and accessible, but not physically refractive. It produces blur/transparency, not bending.
B. SVG displacement over the element’s own pixels
.glass-content {
  filter: url(#displacement);
}
This bends the element itself, but does not bend what is behind it.
C. Cloned/counter-positioned media
<div class="glass">
  <img class="cloned-hero" src="hero.jpg" aria-hidden="true">
</div>
.glass {
  filter: url(#displacement);
}
This can work for controlled media-only cases, such as a hero image behind a header, but it is not equivalent to backdrop refraction over arbitrary page content.
D. DOM clone
Deep-clone whatever is behind the element, counter-position it, and filter it. This is the most visually ambitious workaround but also the least robust.
Requested standardization discussion
I would like the SVG WG / CSS Filter Effects / FXTF groups to consider whether the platform needs a standard model for compositor-safe backdrop inputs to SVG filters.
Possible directions:
1. Define an interoperable backdrop input for filter effects
For example, a filter input similar in spirit to:
<feDisplacementMap
  in="BackdropGraphic"
  in2="map"
  scale="40" />
This would represent the pixels behind the filtered element, clipped to the element/filter region and expressed in a well-defined coordinate space.
Open questions:
* What is the coordinate system?
* Is it defined relative to the border box, padding box, filter region, or backdrop root?
* How does it interact with transforms, scrolling, fixed positioning, and visual viewport changes?
* How does it interact with existing backdrop roots?
* Can it be required to execute only as a one-way rendering effect, without JavaScript pixel readback?
2. Fully specify SVG filters inside 
backdrop-filter
If backdrop-filter: url(#svg-filter) is intended to support arbitrary SVG filters, that support needs interoperable behavior for primitives such as:
* <feDisplacementMap>
* <feImage>
* <feTurbulence>
* <feColorMatrix>
* <feComposite>
* <feGaussianBlur>
If not all primitives can be supported for security/performance reasons, the spec should define which are supported, which are invalid, and how unsupported primitives fail.
3. Define security boundaries for backdrop displacement
Authors do not need JavaScript access to the backdrop pixels. They only need the browser to render a visual effect.
A secure model could specify:
* no canvas readback;
* no JavaScript access to filtered backdrop pixels;
* no timing-sensitive API exposure;
* cross-origin iframes and protected media may render as transparent/solid/isolated;
* user-agent-defined privacy constraints where needed;
* deterministic failure behavior.
4. Define filter region and map sizing behavior for CSS layout boxes
Liquid-glass effects commonly use generated displacement maps that are the same size as the lens element. Authors need predictable sizing.
Important questions:
* How does feImage preserveAspectRatio="none" map into a CSS element’s filter region?
* Should filter primitive coordinate systems be easier to express in CSS pixels?
* Should there be a reliable way to bind a generated image/map to the filter region?
* How should high-DPI device pixel ratios affect map resolution?
5. Consider a higher-level refraction primitive
<feDisplacementMap> is powerful but low-level. It requires authors to precompute x/y displacement maps. Modern UI design may benefit from a standard primitive for common refractive surfaces, such as rounded glass panels.
For example, a future primitive might accept:
* surface height/thickness;
* radius/bevel;
* index of refraction;
* dispersion/chromatic strength;
* blur/saturation contribution;
* edge falloff.
This could be declarative, optimizable, and implementable by user agents in a compositor-friendly way.
Illustrative example only:
<feRefraction
  in="BackdropGraphic"
  radius="24px"
  thickness="12px"
  indexOfRefraction="1.5"
  scale="40"
  result="refractedBackdrop" />
This is not a concrete proposal, just an example of the kind of author-level capability that current SVG filters almost provide but cannot safely/interoperably express over backdrop pixels.
Why this matters now
“Liquid glass” is becoming a mainstream UI design direction. Web authors will increasingly try to reproduce native glass-like surfaces in headers, navigation bars, cards, modals, menus, and controls.
The current platform gives them:
* blur and saturation over live backdrop pixels;
* displacement over an element’s own pixels;
* GPU shaders that cannot sample DOM backdrop pixels;
* no interoperable way to combine live backdrop sampling with displacement/refraction.
This gap pushes authors toward brittle, inaccessible, and inefficient DOM-cloning strategies.
Desired outcome
A web author should be able to express:
“Apply a secure, one-way SVG/CSS filter to the pixels behind this translucent element, including displacement/refraction, in a well-defined coordinate space.”
without:
* cloning DOM;
* duplicating IDs;
* creating hidden focus traps;
* manually tracking scroll offsets;
* rebuilding page content inside WebGL;
* relying on browser-specific bugs or private compositor behavior.
Related evidence / references
* MDN: <feDisplacementMap> uses channel values from in2 to spatially displace the input image.
* MDN: CSS filter can reference an SVG filter via url(...).
* MDN: backdrop-filter applies graphical effects to the pixels painted behind an element and syntax includes SVG filter URLs.
* WebKit Bug 245510: backdrop-filter: url(#some-svg-filter) does not work with SVG filters like <feDisplacementMap>.
* Existing liquid-glass web implementations often work around this by copying/counter-positioning backdrop content and filtering the copy instead of the true backdrop.
Closing
I am not asking for browsers to expose backdrop pixels to JavaScript. I am asking whether SVG/CSS Filter Effects can define a secure, interoperable, compositor-friendly way to use displacement/refraction filters over backdrop pixels.
This would let SVG filter primitives participate in the next generation of glass-like UI design without requiring fragile DOM-cloning or canvas/WebGL workarounds.

(One note: This may belong in SVGWG, CSSWG, or FXTF Filter Effects; I’m filing here because the author-facing primitive is SVG filter-based, but I’d appreciate triage to the correct venue.)

Please view or discuss this issue at https://github.com/w3c/svgwg/issues/1142 using your GitHub account


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

Received on Thursday, 25 June 2026 05:52:29 UTC