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

On 25/01/2016 06:52, Rik Cabanier wrote:
> It's slightly more complicated.
> You need to substitute transparent with 2 coincident stops of the previous
> *and* the next color.

Isn't that what I just said?
See:
>> If transparent is "in the middle" is the only time the list length
>> changes because it needs to have a new stop inserted. I'm sure that inserting
>> an element into an existing list is something all implementations can do :)

In all other cases it suffices to just change the color component:
Transparent -> Color and Color -> transparent (the most common cases on the
web) have transparent on the edge of the gradient, and don't need a second stop.
(r,g,b,0)->(r,g,b,a) and (r,g,b,a)->(r,g,b,0), etc.

Only if you have Color1 -> transparent -> Color2, where Color1 and Color2 are
*different*, do you need 2 stops. If the colors are the same then you don't,
because the color component of transparent would be equal anyway. You could
even optimize it further by only comparing the RGB components for the case of
(r1,g1,b1,a1)->transparent->(r1,g1,b1,a2) since the alpha for either adjacent
color is irrelevant. Not that I think it would be a practical win in terms of
performance or what not.

Even so, inserting an extra entry into an existing list isn't hard, and that
would be more an implementation question than a spec question. Just do this
somewhere between the CSS parsing step and the actual sending it to the
rendering engine step, and you're all good.

Received on Monday, 25 January 2016 14:00:33 UTC