Re: [css-color] color-correction into color-interpolation


On Apr 4, 2013, at 6:40 PM, Rik Cabanier <cabanier@gmail.com> wrote:

> Since color-interpolation is of such questionable value, why don't we just deprecate it?
> It's use can be replaced by using the Lab color spaces since it is linear.
> 

Even if I would agree on deprecating for the general usage on arbitrary shapes, 'color-interpolation' is used on masking and filters as well. All mayor browsers and most viewers support color-interpolation on filters. I think the same is true for masking, but I did not verify that yet.

> If a UA implements color-correction properly, it is also unclear what the 'linear' version of a non-sRGB color is.

This is part of the request. If both properties are not combined, color-correction would need to clarify that.

Greetings,
Dirk

> 
> Rik
> 
> On Thu, Apr 4, 2013 at 4:32 PM, L. David Baron <dbaron@dbaron.org> wrote:
> On Thursday 2013-04-04 16:07 -0700, Dirk Schulze wrote:
> > In the behalf of the SVG WG, I would like to ask it if is possible to merge the 'color-interpolation' property with the 'color-correction' property. We think that they do share similarities.
> >
> > - 'color-interpolation' is a CSS property and should be part of a CSS specification anyway. CSS Color makes most sense here.
> > - SVG has a similar problem as CSS: while SVG requires an sRGB color space, most (maybe all?) implementations use DeviceRGB in reality.
> > - We think 'auto' should be added to 'color-interpolation' to represent this difference
> > - The keyword 'linearRGB' would need to be specified as well, as it is in SVG to switch the color space to linearRGB. 'color-correction' is coming from the WebKit CG implementation which, in theory, is able to use linearRGB.
> 
> I think this is a bad idea.
> 
> 'color-correction' is designed to solve a legacy problem and allow
> documents to opt in to what the spec has required all along (but
> hasn't been implemented, at least partly due to lack of color
> matching with plugins).  It's designed so that if we solve that
> legacy problem (e.g., with changes to the plugin API) we can change
> the initial value or potentially even entirely remove the property's
> effect.  It's also designed to be the smallest possible solution to
> the problem it's trying to solve, allowing authors to specify colors
> in a globally-meaningful way, and thus hopefully the most likely to
> be implemented.
> 
> -David
> 
> --
> 𝄞   L. David Baron                         http://dbaron.org/   𝄂
> 𝄢   Mozilla                           http://www.mozilla.org/   𝄂
> 
>

Received on Sunday, 7 April 2013 16:29:13 UTC