Re: [csswg-drafts] [css-images] @image rule for manipulating images (#6807)

@ydaniv wrote:

> > I expected the images generated by an @image-manipulation rule to always be cached because the manipulations are only applied once to an image. Or are there use cases, in which dynamically applying the rules is required?
> 
> Other use cases are the old `filter()` and others mentioned at the top, which could potentially be animated. So does this rule imply immutability of the result without the ability to animate its properties? I guess further animations could be applied in properties outside of the manipulation effects, which is reasonable.

I see. Regarding the `filter()` function, interpolation (and with that animation) is already [defined in the Filter Effects specification](https://www.w3.org/TR/filter-effects-1/#interpolating-filter-image).

Though I can now see the point for allowing to animate them. One way to achieve that with the proposed syntax would be:

```
@image-manipulation --rotate-image {
  transform: rotate(359deg);
}

@keyframes --rotating-background {
  from: { background-image: url("background.jpg"); }
  to: { background-image: manipulate-image(url("background.jpg"), --rotate-image); }
}

.rotating-background {
  animate: 35.9s --rotating-background infinite;
}
```

Alternatively, we might define the animation directly within the at-rule, i.e. allow the `animation-*` properties as descriptors for the at-rule.
Though as far as I know, the descriptors of at-rules aren't animatable so far. So that would be a novelty. @LeaVerou Feel free to correct me on this.

So an example for that could then look like this:

```
@keyframes --rotate {
  from: { transform: rotate(0deg); }
  to: { transform: rotate(359deg); }
}

@image-manipulation --rotate-image {
  animation: 35.9s --rotate infinite;
}

.rotating-background {
  background-image: manipulate-image(repeating-url("background.jpg"), --rotate-image);
}
```

@booluw wrote:

> > You are right that a new image is created by manipulating the source image. And with `width`, `height` and `aspect-ratio` you can define the sizes of the manipulated image. Though my question was how would a `width: 80%;` be interpreted when the source image doesn't have an intrinsic width? I guess, the answer in that case is that the width of the manipulated image is undefined as well.
> 
> I think a `width: 80%` should be interpreted in relation to the width of the elment the image is been applied to.

Making the manipulations dependent on the element they are used in, would cause significant performance issues [as mentioned by @ydaniv](https://github.com/w3c/csswg-drafts/issues/6807#issuecomment-1153282253). So if you animated the element's width, you'd have to run the manipulation rules for each frame of the animation and each element the rules are applied to.

Sebastian

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


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

Received on Monday, 13 June 2022 12:25:52 UTC