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

On 12/04/2016 04:36, Florian Rivoal wrote:
>>>
>>> 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.
>>
>> Note that I was talking about animating plain colors, not gradients.
>> Of course animating gradients requires more math when 'transparent' is
>> special-cased, though it isn't that complicated either.
> 
> While I see the potential benefit of making transparent magic, I am not entirely sure how you'd animate. If the author is asking for an animation from linear-gradient(red, white ,blue) to linear-gradient(red, transparent, blue), what do you do?
> 
> Something like the following steps?
> 
> linear-gradient(red, rgba(255,255,255,1), blue) /*(red, white ,blue)*/
> linear-gradient(red, rgba(255,255,255,0), blue)
> linear-gradient(red, rgba(255,255,255,0) 50%, rgba(255,255,255,0) 50%, blue)
> linear-gradient(red, rgba(255,0,0,0) 50%, rgba(0,0,255,0) 50%, blue) /*(red, "magic" transparent, blue)*/
> 
>  - Florian
> 

I already posted an example implementation (which still has room for further
optimization/tweaking! but is fairly simple otherwise, and other approaches
can of course also be considered in different implementations to keep the
gradients and animations smooth) to transition from/to a special-cased
transparent stop in a previous message but it may possibly not have made it to
the list, because I wasn't subscribed when mailing it in the first time. I'll
post the example implementation below again, sorry if this is a double post as
a result.

Repost of relevant parts:

===

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.

[...]

[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.

===

Of course going to transparent would be the reverse.

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

Mark.

Received on Tuesday, 12 April 2016 08:19:27 UTC