Re: [css-color] wider/deeper colors

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.

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 00:41:28 UTC