Re: [css-color] wider/deeper colors

> On Feb 11, 2016, at 11:40 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> On Wed, Feb 3, 2016 at 1:51 AM, Dean Jackson <dino@apple.com> wrote:
>>>> 2. We will add a new function for describing colors that accepts a
>>>> color-profile name and a variable number of arguments. e.g.
>>>> color("bt2020", 0.7, 0.3, 0.1). The name can be linked to a
>>>> @color-profile, but we will also have some predefined keywords for
>>>> the most common profiles.
>>> 
>>> Yes, exactly. I was thinking of icc rather than color, which is
>>> shorter and more descriptive (these are icc profiles).
>> 
>> That sounds fine by me.
> 
> Yeah, I like icc() fine.

I dislike this name. icc is short for "International Color Consortium”, and that doesn’t make sense as a function name to me.

Is CSS going to spec the acceptable list of ICC profile names, or is this left undefined?

Simon

> 
> Note to Chris: per fantasai's and my general rule that functions are
> just a way of separating/naming chunks of CSS syntax and act like
> normal CSS syntaxes, let's omit commas unless necessary.  In
> particular, icc() should probably have the grammar:
> 
> icc( <string> <number>+ , <alpha-value>? )
> 
> Because the inputs to a profile aren't parallel iterations on a
> concept (the usual trigger for comma usage in properties), so they
> should just be space-separated.  Comma-separating the alpha value
> matches the other color functions, and separates it grammatically from
> the profile inputs (which might not always have a fixed arity, I
> dunno).
> 
>> While we could come up with media queries that detect all
>> these things individually (extended gamut accepted as input,
>> extended gamut supported on output, greater bit depth as input,
>> greater bit depth preserved on output, number of bits per
>> channel, etc), I think a more simple media query works in the
>> majority of cases: developers just want to know if the hardware
>> and software stack on the user's computer supports "better"
>> colours than today's typical hardware.
> 
> I agree with your reasoning; my only concern is what to name the
> "better" value that'll allow us to discriminate between "new normal"
> and "even more betterer" in ten years, when devices with deeper/wider
> colors than 3*8 are commonplace.
> 
>>>> 3.a (alternate) Florian suggested something more like @supports,
>>>> where you give something from points 1 or 2 above, and the system
>>>> will tell you if it could handle it. I like this idea, but we'd need
>>>> to be careful to describe what it means to handle the color.
>>> 
>>> That seems odd; for an icc-aware system it is asking if it could
>>> handle a given icc profile. Except for v.2 implementation vs v.4
>>> profile issues, the answer is always "yes".
>> 
>> I think the intent was "will this color be accurately displayed
>> or will it be clipped/mapped/munged"?
> 
> Simple use of @supports, like "@supports (color: icc(...)) {...}"
> won't do this - it'll return yay/nay based on whether the declaration
> parses, which at *most* will let you know whether or not the profile
> is recognized (assuming we make unknown profiles invalid, which we
> probably should).  But we made the grammar for @supports extra-wide
> for a reason - we can add something like "@supports icc(...) {...}",
> which'll return yay if the UA knows the hardware can handle that
> *particular* color without munging, and nay otherwise.
> 
> ~TJ
>

Received on Thursday, 11 February 2016 03:00:06 UTC