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

On 24/01/2016 06:37, Rik Cabanier wrote:
> The graphics frameworks in the browsers all interpolate in non-premultiplied
data. I had to add emulation code to all the browsers to make this happen.

So there's even less of a reason then to not change this...
Sorry to hear that so much extra work has been put into something that could
have been solved with the proposed approach the first time.

> Like Mark, I proposed to treat transparent special but it fell on deaf ears
> [1]. I remember Tab and dbaron especially being opposed.
> Unfortunately, now that Ion and I made all browsers compliant, it's likely too
> late to make this change

I don't think it's ever too late to make an improvement to a spec that is
beneficial for all involved and has no negatives. This is done all the time on
other specs, so why not here?

I understand that this might impact certain websites that explicitly rely on
premultiplied colors, but the common case (fade to transparent) would not be
affected.
It would need 2 changes to the spec:
1. Change the definition of "transparent" as a keyword to not be a shorthand
for rgba(0,0,0,0) but rather a transparent version of the adjacent color
2. Change the color space to use to be non-premultiplied RGBA

For the record, I've looked at implementing this special case for
'transparent' in my Mozilla-derived browser and it was *very* simple to do. I
gather all implementations in browsers would use a list (e.g. array or linked
list) of stops; all it takes is changing the "transparent" stop from
"transparent black" to the adjacent color value (previous or next) with
opacity 0. 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 :)

Received on Sunday, 24 January 2016 13:23:31 UTC