Re: [csswg-drafts] [css-color] [filter-effects] Should no-op filters produce different output from no filter? (#7100)

> Chrome appears to not follow this spec text precisely, and seems (on macOS at least) to apply filters in some extended sRGB colorspace (tested on iMac Pro with DisplayP3 display).

I have filed [a Chrome bug](https://issues.chromium.org/issues/373410239) for this. This should not happen when I'm explicitly setting `color-interpolation-filters` to `sRGB`.

The fact that Chrome does this makes using SVG filters to create cool effects like split and offset with no content duplication completely useless.

For example, a split text effect. I put the text on the blue channel `rgb(0% 0% 100%)`. And then I blend it with a pseudo that has a sharp CSS gradient split between 100% on the red channel, 0% on the others and 100% on the green channel, 0% on the others. In theory, I should be able to to do:

```
background: 
  linear-gradient(rgb(0% 0% 100%) 0 0) text, 
  linear-gradient(var(--ang), rgb(100% 0% 0%) 50%, rgb(0% 100% 0%) 0) border-box;
background-blend-mode: lighten
```

In practice, this fails in both [Firefox](https://bugzilla.mozilla.org/show_bug.cgi?id=1481498) and [Safari](https://bugs.webkit.org/show_bug.cgi?id=267129) due to `background-clip: text` related bugs.

In the SVG `filter`, I extract the intersection of the areas with both the blue channel and each of the red and green channels maxed out separately and I offset the two areas in different directions to get the split & offset text effect.

Except this doesn't work well with Chrome on wide gamut devices and leaves dirty, partly painted areas where there shouldn't be.

For example, we get this:

<img width="680" alt='Broken look screenshot. Screenshot. Shows the text "slice" in all caps, split into three by two slightly angled, not quite parallel lines. The top and bottom parts are a dirty, grainy white and are also offset to the left and right respectively. They also cast shadows on top of the middle one, which is a grainy yellowish green. The dark background behind is also grainy. Unfortunately, the top and bottom parts also get what looks like an ugly muddy grey background, as well as muddy grey copies of the no offset letters.' src="https://github.com/user-attachments/assets/54f6169c-2281-464d-bcb8-0dc88c406b8e" />

Instead of the correct result for [this demo](https://codepen.io/thebabydino/pen/GRaKbZo):

<img width="680" alt='Correct look screenshot. Screenshot. Shows the text "slice" in all caps, split into three by two slightly angled, not quite parallel lines. The top and bottom parts are a dirty, grainy white and are also offset to the left and right respectively. They also cast shadows on top of the middle one, which is a grainy yellowish green. The dark background behind is also grainy.' src="https://github.com/user-attachments/assets/4d7e0d14-44d6-4167-8570-627252230303" />

Not only I don't own one, but I don't have access to any wide gamut device and don't know anyone in real life who has. So for almost a year, I made a few hundreds of these kind of demos with no duplication slice & offset effects on text, images and more... before learning anything was wrong anywhere.

I then thought about [using `oklch()` instead](https://codepen.io/thebabydino/pen/YPwpbXj), except `oklch()` makes no sense at all and I have no idea what values to use that are going to max out just one of the RGB channels on devices I don't even have access to. So I figured just bump up the chroma to a ridiculous value like `9` should do? Except okay for the red and green channels, but a `240deg` hue doesn't give me just the blue channel anymore in that case for `oklch()`. So which is the right angle if it's not equidistant to `120deg`/ `360deg`? `210deg`?

¯\_(ツ)_/¯

Furthermore, when using the `oklch()` version, angled/ arched edges of areas extracted using a channel or another look jagged and ugly.

But the worst of it is gradients. The alpha maps I pass from the CSS via the RGB channels aren't always just 100% somewhere and `0%` elsewhere. Sometimes I want gradients from `0%` to `100%`. Sometimes I use the gradients I pass from the CSS (where they may depend on a variable that transitions on `:hover`) to the SVG filters as displacement maps to emulate [3D effects on hover](https://bsky.app/profile/anatudor.bsky.social/post/3lbtsor5p622y). And when using the `oklch()` version to get around the Chrome wide gamut bug, [the gradients are completely broken](https://codepen.io/thebabydino/pen/YPWzGoN).

So I think Chrome should just fix this to follow the spec.

-- 
GitHub Notification of comment by thebabydino
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7100#issuecomment-3689069818 using your GitHub account


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

Received on Wednesday, 24 December 2025 08:24:18 UTC