Re: [css-images] Negative implications of linear gradient color space choice in CSS

Hey Folks,

On 09/04/2016 01:12, Sebastian Zartner wrote:
>> This has multiple, significant effects on animation, too.
>> "transparent" is no longer an animatable value (impossible to smoothly
>> move from it to any other color), so any gradient using "transparent"
>> stops being animatable too. To make it animatable, you have to
>> manually put in the two RGBA steps, which means you have to double-up
>> that step for any other gradient you're animating with this one.
> 
> The same rules for gradient color transitions apply to animations. So
> it would still be animatable.
> Reusing the example from above the transtion between the colors would
> be rgba(255,0,0,1) @ 0% -> rgba(255,0,0,0) @ 50% -> rgba(0,0,255,0) @
> 50% -> rgba(0,0,255,1) @ 100% for an animation like this:
> 
[snip]

I think Tab's main objection is that a transparent stop itself (especially
when "in the middle") would be more difficult to animate to another
(not-transparent) color because it would influence the surrounding gradients
rather sharply.

The simple animation scenario indeed applies without issue, but only if you're
talking about animating the adjacent colors [a]- but considering the nature of
the transparent stop being dependent on the adjacent stop already, the
transparent stop will simply follow whatever color the adjacent stop animates
to, to keep the gradient a single hue.

If you're actually animating the transparent stop itself to something not
transparent it's still simple on the edge [b] and only if you're looking at a
transparent stop in the middle [c] it's more complex but certainly not
impossible. The trick there is that you need 3 stops in your implementation.
Why? because you're actually looking at a *sharp edge* at the transparent
point that would influence the gradients with a naive averaging approach.

Nobody said animating accurate gradients was simple in all cases ;)

However, I don't see problems implementing any of these scenarios:

[a] is extremely simple and just needs the color value of the adjacent stop
copied to the color value of the transparent stop each animation step if it
remains a transparent stop. If you previously optimized the transparent stop
to be a single one (for equal adjacent colors either side) and adjacent colors
animate to different ones, then you need to create a second stop for unequal
color values either side of transparent.

[b] is also very simple since you can just transition from the transparent
adjacent color to the target color.

[c] is a little more complex. It's still some straightforward math to make an
animation-dependent average mid point. When it comes down to a usable
approach, all you have to do is look at what you start with and what you need
to end with.
Since you start off with a sharp edge as far as color is concerned (although
not visually), you need to not just double-up, but create an intermediate,
sliding stop on either side (going from 50% position to 25%||75% at
completion) that starts at the transparent stop and ends at halfway between
the transparent stop and the adjacent color at the midpoint values.

If absolutely needed I can take some time to write a paper how to do this (I'd
rather not, I'm quite busy as it is already), but basically you'd end up with
the following:
start of animation (0):
L - T - R -> rendered as L - TL||TR - R
We're going to transition T(ransparent) to a new color C with alpha A
for animation, the starting situation should be considered as
L - TL||T||TR - R, where T = the target color C with alpha 0
at 20% animation:
L - (90%L+10%C, 20%A)@45% - (C, 20%A)@50% - (90%R+10%C, 20%A)@55% - R
at 50% animation:
L - (75%L+25%C, 50%A)@37.5% - (C, 50%A)@50% - (75%R+25%C, 50%A)@62.5% - R
at 100% animation:
L - (50%L+50%C, 100%A)@25% - (C, 100%A)@50% - (50%R+50%C, 100%A)@75% - R
which is exactly the same as an L - C - R gradient.

I think all of these situations/actions will lead to smooth animations. So it
most certainly remains animatable although with a little bit more math
involved due to the sharp edge in the latter case.

I hope this takes away some doubts about potential roadblocks for the
suggested revision.

Mark.

Received on Monday, 11 April 2016 17:23:48 UTC