[css-color] wider/deeper colors

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
80 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

[css-color] wider/deeper colors

Dean Jackson-7
In preparation for discussion of this topic at the face-to-face meeting, a summary of where (I think) we are on this topic:

0. Firstly, not much has changed since my last email thread on this topic, which has some good discussion [1].

1. The specification already allows values outside of [0,1] inside the rgb() function, although no-one implements it yet. However, we don't describe what such values actually mean. I think we should investigate describing them as using the scRGB space [2].

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.

2.a (alternate) Similar to 2 but just add a function that accepts BT.2020 because "640kb ought to be enough for anybody".

3. Add a media query to enable detection of a hardware and software stack that will process colors outside of sRGB. This could take the form of "awesome-colors: none | some | plenty" which map to what most people have today, something about DCI P3, and then something about BT.2020 (i.e intentionally slightly vague), or something that allows detection of a named profile.

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. 


Dean

Reply | Threaded
Open this post in threaded view
|

Re: [css-color] wider/deeper colors

Marat Tanalin | tanalin.com
31.01.2016, 22:57, "Dean Jackson" <[hidden email]>:
> In preparation for discussion of this topic at the face-to-face meeting

FWIW, there was a related discussion [1] on 2013-12-09.

> e.g. color("bt2020", 0.7, 0.3, 0.1).

As I said earlier [2], with deeper color spaces, it would be good to still have a way to specify an _exact_ color like we currently can using hex notation. With approx-by-nature floating-point notation like `0.7`, this is in fact impossible.

[1] https://lists.w3.org/Archives/Public/www-style/2013Dec/0165.html
[2] https://lists.w3.org/Archives/Public/www-style/2013Dec/0169.html

Reply | Threaded
Open this post in threaded view
|

Re: [css-color] wider/deeper colors

Chris Lilley
In reply to this post by Dean Jackson-7
Hello Dean,

Sunday, January 31, 2016, 9:52:38 PM, you wrote:

> In preparation for discussion of this topic at the face-to-face
> meeting, a summary of where (I think) we are on this topic:

I will try to join this discussion by phone.

> 0. Firstly, not much has changed since my last email thread on this
> topic, which has some good discussion [1].


> 1. The specification already allows values outside of [0,1] inside
> the rgb() function, although no-one implements it yet.

Correct. they don't do for several reasons; a major one is because the
transfer curve is non-linear and thus is only defined inside [0,1].
There are some plausible ways to extend it below zero (continue the
linear portion is one; mirror the transfer curve about zero is
another). It is even worse for values greater than 1, as the curve is
already fairly flat so you have to extend a lot to get any actual
increase. xvYCC defines another way to do this.

A second one is that many color management systems, until recently,
did early clamping because hey could not handle values outside [0,1]
anyway.

A third reason is that, while it is theoretically true that values
outside of [0,1] can be used to describe any out of gamut color, in
practice such colors are specified in Lab.

>  However, we
> don't describe what such values actually mean. I think we should
> investigate describing them as using the scRGB space [2].

scRGB is a good choice because it has a linear transfer function.

The video industry has instead chosen xvYCC
 https://en.wikipedia.org/wiki/XvYCC
because conversion to sRGB gamut can be done by simple clamping, and
because it is compatible with JPEG (and other MPEG) YCC systems.

> 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).

SVG used icc-color which is a bit long. It also required an sRGB
fallback everytime, which on reflection is not actually needed (if the
implementation is icc-unaware, the user can provide a fallback in the
usual CSS way; if it is icc-aware, then it can produce an Lab or XYZ
or sRGB value for those situations where one is needed).

> 2.a (alternate) Similar to 2 but just add a function that accepts
> BT.2020 because "640kb ought to be enough for anybody".

Less extensible than the first option and not really worth it;
increases spec pressure to add new values; prevents using color
managed cmyk or hexachrome profiles.

> 3. Add a media query to enable detection of a hardware and software
> stack that will process colors outside of sRGB.

Yes. I hope we have some good discussion on this one. Would this go
into MQ4 or color-4?

> This could take the
> form of "awesome-colors: none | some | plenty" which map to what
> most people have today, something about DCI P3, and then something
> about BT.2020 (i.e intentionally slightly vague), or something that
> allows detection of a named profile.

A bit wooly :)

There are two somewhat independent capabilities to be queried here,
bit depth (also called deep color by the video industry) and extended
gamut. I say somewhat independent because you typically need them
both, to avoid banding.

The third capability is icc-awareness, which in practice has three
values (none, v2, v4).
(Yes, there is no v1 or v3 of ICC :)

> 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".


--
Best regards,
 Chris  Lilley
 Technical Director, W3C Interaction Domain


Reply | Threaded
Open this post in threaded view
|

Re: [css-color] wider/deeper colors

Dean Jackson-7
Hi Chris,

> On 2 Feb 2016, at 00:27, Chris Lilley <[hidden email]> wrote:
>
> Sunday, January 31, 2016, 9:52:38 PM, you wrote:
>
>> In preparation for discussion of this topic at the face-to-face
>> meeting, a summary of where (I think) we are on this topic:
>
> I will try to join this discussion by phone.

Unfortunately it happened the day before you sent this message.
Your expertise was missed!

The TLDR is that we're waiting on you to make a more
detailed proposal, but I might make one in the meantime
(which I would expect you to tear apart and improve).

>
>> 0. Firstly, not much has changed since my last email thread on this
>> topic, which has some good discussion [1].
>
>
>> 1. The specification already allows values outside of [0,1] inside
>> the rgb() function, although no-one implements it yet.
>
> Correct. they don't do for several reasons; a major one is because the
> transfer curve is non-linear and thus is only defined inside [0,1].
> There are some plausible ways to extend it below zero (continue the
> linear portion is one; mirror the transfer curve about zero is
> another). It is even worse for values greater than 1, as the curve is
> already fairly flat so you have to extend a lot to get any actual
> increase. xvYCC defines another way to do this.
>
> A second one is that many color management systems, until recently,
> did early clamping because hey could not handle values outside [0,1]
> anyway.
>
> A third reason is that, while it is theoretically true that values
> outside of [0,1] can be used to describe any out of gamut color, in
> practice such colors are specified in Lab.

We asked Adobe for some feedback on how they expect the workflow
for these situations to go. How will authors pick colors? How will
the colors in the authoring tool be exported to a syntax that
CSS can accept?

It's not (yet) clear if authoring such values by hand will make any
sense. If you consider the r, g and b inputs as infinite axes, then
I guess you can imagine someone wanting "more red" and bumping
past 100%. However, the result isn't really that simple.

Anyway, more descriptions of color workflows, in any use case,
would be appreciated.

>
>> However, we
>> don't describe what such values actually mean. I think we should
>> investigate describing them as using the scRGB space [2].
>
> scRGB is a good choice because it has a linear transfer function.
>
> The video industry has instead chosen xvYCC
> https://en.wikipedia.org/wiki/XvYCC
> because conversion to sRGB gamut can be done by simple clamping, and
> because it is compatible with JPEG (and other MPEG) YCC systems.
>
>> 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.

>
> SVG used icc-color which is a bit long. It also required an sRGB
> fallback everytime, which on reflection is not actually needed (if the
> implementation is icc-unaware, the user can provide a fallback in the
> usual CSS way; if it is icc-aware, then it can produce an Lab or XYZ
> or sRGB value for those situations where one is needed).
>
>> 2.a (alternate) Similar to 2 but just add a function that accepts
>> BT.2020 because "640kb ought to be enough for anybody".
>
> Less extensible than the first option and not really worth it;
> increases spec pressure to add new values; prevents using color
> managed cmyk or hexachrome profiles.

Yes, this wasn't something we were pushing for, unless the
main option was going to be too complicated to make happen in
a reasonable time.

>
>> 3. Add a media query to enable detection of a hardware and software
>> stack that will process colors outside of sRGB.
>
> Yes. I hope we have some good discussion on this one. Would this go
> into MQ4 or color-4?

I don't know.

>
>> This could take the
>> form of "awesome-colors: none | some | plenty" which map to what
>> most people have today, something about DCI P3, and then something
>> about BT.2020 (i.e intentionally slightly vague), or something that
>> allows detection of a named profile.
>
> A bit wooly :)
>
> There are two somewhat independent capabilities to be queried here,
> bit depth (also called deep color by the video industry) and extended
> gamut. I say somewhat independent because you typically need them
> both, to avoid banding.
>
> The third capability is icc-awareness, which in practice has three
> values (none, v2, v4).
> (Yes, there is no v1 or v3 of ICC :)

Right. Apple ships hardware with extended gamut. Simon may
correct me, but I don't think we ship any Web-facing features (yet)
that have a greater bit depth.

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.

Noel from Google (who might be reading this) expressed it
pretty well to me in person today: I'm selling red shoes. What do
I do to get a photo on my web page that most accurately
shows the shoes to the customer?

Obviously a lot depends on the quality of the display and
especially the viewing environment, but maybe just knowing
there is a good/better/best display on the other end, along
with a browser that will take advantage of it, is a good
start.

>
>> 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"?

Dean



Reply | Threaded
Open this post in threaded view
|

Re: [css-color] wider/deeper colors

Tab Atkins Jr.
On Wed, Feb 3, 2016 at 1:51 AM, Dean Jackson <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [css-color] wider/deeper colors

Dean Jackson-7

> On 11 Feb 2016, at 11:40 AM, Tab Atkins Jr. <[hidden email]> wrote:
>
> 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.

Yeah. I haven't come up with anything even remotely good for names here.

We could ignore it slightly and use "level1", "level2", etc. Or use years
like "2016", "2019" to mean the type of display you'd expect to get for
a purchase of x% of median wage in that year. It's the new arm length!
It might require predicting the future :)

I did say I haven't come up with anything good.

Dean


Reply | Threaded
Open this post in threaded view
|

Re: [css-color] wider/deeper colors

Simon Fraser-4
In reply to this post by Tab Atkins Jr.

> On Feb 11, 2016, at 11:40 AM, Tab Atkins Jr. <[hidden email]> wrote:
>
> On Wed, Feb 3, 2016 at 1:51 AM, Dean Jackson <[hidden email]> 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
>


Reply | Threaded
Open this post in threaded view
|

Re: [css-color] wider/deeper colors

Florian Rivoal-4
In reply to this post by Tab Atkins Jr.

> On Feb 11, 2016, at 09:40, Tab Atkins Jr. <[hidden email]> wrote:
>
> On Wed, Feb 3, 2016 at 1:51 AM, Dean Jackson <[hidden email]> 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>? )


Bikesheding the function name aside, I think it would be good if the syntax could allow things like:

  color("pantone" "P 71-7 C")

which makes me think the syntax should be something like

  color( <string> [ <number>+ | <string> ] [, <alpha-value> ]? )

Maybe custom properties mean that we don't need a special syntax for named colors, but I would still much prefer being able to say
  background: color("pantone" "P 71-7 C");
than
  background: var(--pantone_P_71-7_C);

 - Florian
Reply | Threaded
Open this post in threaded view
|

Re: [css-color] wider/deeper colors

Florian Rivoal-4
In reply to this post by Simon Fraser-4

> On Feb 11, 2016, at 11:59, Simon Fraser <[hidden email]> wrote:
>
>
>> On Feb 11, 2016, at 11:40 AM, Tab Atkins Jr. <[hidden email]> wrote:
>>
>> On Wed, Feb 3, 2016 at 1:51 AM, Dean Jackson <[hidden email]> 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?

I tend to prefer color() over icc() as well. As for where the profile names come from, should at least hardcode sRGB, and could hardcode a few more, but in general I expect that we would also have an @rule to declare color spaces.

@colors "adobe-rgb" {
  profile: url("https://www.example.com/adobe.icc");
}


 - Florian
Reply | Threaded
Open this post in threaded view
|

Re: [css-color] wider/deeper colors

Justin Novosad


On Thu, Feb 11, 2016 at 7:15 AM, Florian Rivoal <[hidden email]> wrote:

> On Feb 11, 2016, at 11:59, Simon Fraser <[hidden email]> wrote:
>
> 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?

I tend to prefer color() over icc() as well. As for where the profile names come from, should at least hardcode sRGB, and could hardcode a few more, but in general I expect that we would also have an @rule to declare color spaces.

I agree icc() is not good. As far as color profiles are concerned, icc is just the name of the standard we currently use for encoding them. Using that name would be equivalent to naming the image tag <png>.
If you bake in a notion of a particular format or standard, in the future you end up with questions like: Why is there an "Xml" in front of "HttpRequest"?


Reply | Threaded
Open this post in threaded view
|

Re: [css-color] wider/deeper colors

Simon Fraser-4
In reply to this post by Florian Rivoal-4

On Feb 11, 2016, at 4:15 am, Florian Rivoal <[hidden email]> wrote:


On Feb 11, 2016, at 11:59, Simon Fraser <[hidden email]> wrote:


On Feb 11, 2016, at 11:40 AM, Tab Atkins Jr. <[hidden email]> wrote:

On Wed, Feb 3, 2016 at 1:51 AM, Dean Jackson <[hidden email]> 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?

I tend to prefer color() over icc() as well. As for where the profile names come from, should at least hardcode sRGB, and could hardcode a few more, but in general I expect that we would also have an @rule to declare color spaces.

@colors "adobe-rgb" {
 profile: url("https://www.example.com/adobe.icc");
}

I think we’re prefer to avoid referencing external resources for colors. What do you show before the resource is available? Transparent?

Simon

Reply | Threaded
Open this post in threaded view
|

Re: [css-color] wider/deeper colors

Dean Jackson-7
In reply to this post by Dean Jackson-7

> On 11 Feb 2016, at 12:06 PM, Dean Jackson <[hidden email]> wrote:
>
>
>> On 11 Feb 2016, at 11:40 AM, Tab Atkins Jr. <[hidden email]> wrote:
>>
>> 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.
>
> Yeah. I haven't come up with anything even remotely good for names here.
>
> We could ignore it slightly and use "level1", "level2", etc. Or use years
> like "2016", "2019" to mean the type of display you'd expect to get for
> a purchase of x% of median wage in that year. It's the new arm length!
> It might require predicting the future :)
>
> I did say I haven't come up with anything good.

I'm now flip-flopping back to something that uses existing, well-known profiles, which wasn't exactly what we originally proposed, but I think they make more sense.

Here is the text:

>>> 1. Add a new media query that is able to detect the "depth" of the display. I put that word in quotes because I think the current "color" query isn't sufficient and we need a term to better describe what we're trying to detect. The "color" query examines the number of bits per channel, but that doesn't allow you to ask if the display can show things outside sRGB. Instead we suggest there should be range-type query that allows you to detect "normal" (typical displays from today, in the sRGB range or about), "extended" (wider gamut displays, in the DCI P3 range or about) and "super-awesome-needs-a-better-name" displays (very wide gamut displays, in the Rec. 2020 range or about). I believe this might be the first media query that has named values but works as a range. We don't have good suggestions for the name of this query.

(#include the color expert equivalent of "I am not a lawyer")

I suggest the name of the query be "color-support". It implies that the software and hardware do their best effort to represent colors of this range.

I think we might be able to get away with three values.

color-support: sRGB | P3 | Rec2020

or

color-support: sRGB-equivalent | P3-equivalent | Rec2020-equivalent

… because there are many different forms of P3 (e.g. Photoshop allows you to choose from 8!) and not all displays might be the same. For the Apple iMacs, we suggest people use the "Display P3" profile when authoring artwork. As far as I can tell, these three values would cover the two most well-known and supported important steps up from what is common today. And we can add new steps if necessary.

I guess the main point is that we can't really be specific here, because there are lots of choices, and you can find many articles that describe how existing Ultra-HDTVs say they support Rec 2020 but at best cover 90% of the gamut. What we're trying to achieve is a way to allow a developer to at least try to provide images that are the most accurate for the user's configuration (e.g. they want to send a P3 image if possible, but otherwise would be better off sending an sRGB image rather than risking clamping).

I'm planning to send a pull request with this proposal soon (if that's how it is done in CSS).

Dean


Reply | Threaded
Open this post in threaded view
|

Re: [css-color] wider/deeper colors

Florian Rivoal-4
In reply to this post by Simon Fraser-4

On Feb 12, 2016, at 11:16, Simon Fraser <[hidden email]> wrote:


On Feb 11, 2016, at 4:15 am, Florian Rivoal <[hidden email]> wrote:


On Feb 11, 2016, at 11:59, Simon Fraser <[hidden email]> wrote:


On Feb 11, 2016, at 11:40 AM, Tab Atkins Jr. <[hidden email]> wrote:

On Wed, Feb 3, 2016 at 1:51 AM, Dean Jackson <[hidden email]> 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?

I tend to prefer color() over icc() as well. As for where the profile names come from, should at least hardcode sRGB, and could hardcode a few more, but in general I expect that we would also have an @rule to declare color spaces.

@colors "adobe-rgb" {
 profile: url("https://www.example.com/adobe.icc");
}

I think we’re prefer to avoid referencing external resources for colors. What do you show before the resource is available? Transparent?

That's a real issue, and we should find some way of dealing with the fall back, but I don't think we can have a solution that
does not allow for external color profiles. Otherwise we're not going to be able to do color matching with images, or to have print specific color profiles

Maybe specifiying in the at-rule what kind of color model we're defining can give us an idea (even if approximate) of what to do when the resource hasn't loaded.

@colors "name" {
  profile: url() | from-image();
  model: rgb | xyz | cmyk | ...;
}

Or maybe we can extend the color function to have an explicit fallback. 

Or maybe we can define that the color function defaults to currentColor, or do that in most contexts but default to the background color in other contexts.

Or maybe all of the above.

 - Florian
Reply | Threaded
Open this post in threaded view
|

Re: [css-color] wider/deeper colors

aaron.www-style-
In reply to this post by Dean Jackson-7
Something that would benefit from alternative colorspaces even without
wider display gamut are CSS gradients.

Currently they're done in sRGB which leads to some fairly ugly results
when blending hues[1].

David Baron suggested[2] that extending SVG's color-interpolation
property to cover gradients might help.

The downside tehre is that the only offered alternative, linear sRGB,
would fix the hue issue it would do so at expense of luminosity
transitions, e.g. in grey-grey gradients.

Ideally blending in some perceptually uniform space would be an option
since it likely reflects author intent.

Similarly gradients could benefit from deeper colors even on 8bit
displays simply by dithering the output to 8bit.

- Aaron


[1] https://bug1248178.bmoattachments.org/attachment.cgi?id=8719199
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1248178#c2


Reply | Threaded
Open this post in threaded view
|

Re: [css-color] wider/deeper colors

Lea Verou-2
In reply to this post by Simon Fraser-4

On 11Feb, 2016, at 21:16, Simon Fraser <[hidden email]> wrote:

I think we’re prefer to avoid referencing external resources for colors. What do you show before the resource is available? Transparent?

Simon

That is something we'll need to solve, just like all the discussions about the @font-face fallbacks.
What exactly is the alternative to not referencing external resources?! Just having a list of keywords and if the author wants to reference something else, well, touch luck?

~Lea
Reply | Threaded
Open this post in threaded view
|

Re: [css-color] wider/deeper colors

L. David Baron
On Tuesday 2016-02-16 02:30 -0500, Lea Verou wrote:
> > On 11Feb, 2016, at 21:16, Simon Fraser <[hidden email]> wrote:
> > I think we’re prefer to avoid referencing external resources for colors. What do you show before the resource is available? Transparent?
>
> That is something we'll need to solve, just like all the discussions about the @font-face fallbacks.
> What exactly is the alternative to not referencing external resources?! Just having a list of keywords and if the author wants to reference something else, well, touch luck?

This seems rather different from fonts, in that specifying a fixed
set of alternatives (i.e., a list of color spaces known to CSS), if
done right, doesn't limit what developers can do, only how they can
do it (which is something language designers limit all the time).
If the color spaces specified in CSS can represent the range of
colors that developers want to specify, there isn't (I don't think)
a loss of capability in forbidding other options.  And there is a
gain, in terms of simplicity of the platform and avoiding dealing
with the bandwidth and complexity of loading external resources.

-David

--
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [css-color] wider/deeper colors

Lea Verou-2

> On 16Feb, 2016, at 03:07, L. David Baron <[hidden email]> wrote:
> […]
>
> This seems rather different from fonts, in that specifying a fixed
> set of alternatives (i.e., a list of color spaces known to CSS), if
> done right, doesn't limit what developers can do, only how they can
> do it (which is something language designers limit all the time).
> If the color spaces specified in CSS can represent the range of
> colors that developers want to specify, there isn't (I don't think)
> a loss of capability in forbidding other options.  And there is a
> gain, in terms of simplicity of the platform and avoiding dealing
> with the bandwidth and complexity of loading external resources.
>
> -David

How exactly do you imagine this working? How many ICC profiles will we alias? Do you have a set in mind that “developers want to specify”? If I want to specify colors with the color profile of my specific monitor, how I will do so? If I want to specify colors that match a specific printer's output, how will I do that?
Color profiles are not just sRGB and Adobe RGB. I have not seen a single application or language that supports ICC color profiles but limits them to a hardcoded list of “approved” profiles, “preselected for your convenience”.
Having all the syntax and implementation for ICC profiles and not allowing arbitrary ones is so wasteful it makes kittens cry. :)

~Lea


Reply | Threaded
Open this post in threaded view
|

Re: [css-color] wider/deeper colors

Chris Lilley
In reply to this post by aaron.www-style-
Hello aaron,

Monday, February 15, 2016, 11:42:02 PM, you wrote:

> Something that would benefit from alternative colorspaces even without
> wider display gamut are CSS gradients.

> Currently they're done in sRGB which leads to some fairly ugly results
> when blending hues[1].

> David Baron suggested[2] that extending SVG's color-interpolation
> property to cover gradients might help.

It would help, yes. (Actually not an extension, in SVG it already does
that, but applying the property to html/css would help there).

> The downside tehre is that the only offered alternative, linear sRGB,
> would fix the hue issue it would do so at expense of luminosity
> transitions, e.g. in grey-grey gradients.

Yes, just those two options is too limited.

> Ideally blending in some perceptually uniform space would be an option
> since it likely reflects author intent.

Since we are adding Lab as a colorspace, then adding it as a value to
color-interpolation makes a lot of sense too. Perceptually linear, no
gamut clipping.

> Similarly gradients could benefit from deeper colors even on 8bit
> displays simply by dithering the output to 8bit.

Yes (as is done currently with 8bit colors, dithered to 6bits on TN
displays).



--
Best regards,
 Chris  Lilley
 Technical Director, W3C Interaction Domain


Reply | Threaded
Open this post in threaded view
|

Re: [css-color] wider/deeper colors

Chris Lilley
In reply to this post by Florian Rivoal-4
Hello Florian,

Thursday, February 11, 2016, 12:45:00 PM, you wrote:
> Bikesheding the function name aside, I think it would be good if
> the syntax could allow things like:

>   color("pantone" "P 71-7 C")

Or more generally, and sidestepping the issue of trademarked lists of
names, it would be good if "named color" profiles were supported.

Pantone happens to be one example which could be implemented like
that, technically, if the license conditions allowed it which they
don't.

> which makes me think the syntax should be something like

>   color( <string> [ <number>+ | <string> ] [, <alpha-value> ]? )

Yes.


--
Best regards,
 Chris  Lilley
 Technical Director, W3C Interaction Domain


Reply | Threaded
Open this post in threaded view
|

Re: [css-color] wider/deeper colors

L. David Baron
In reply to this post by Lea Verou-2
On Tuesday 2016-02-16 03:20 -0500, Lea Verou wrote:

>
> > On 16Feb, 2016, at 03:07, L. David Baron <[hidden email]> wrote:
> > […]
> >
> > This seems rather different from fonts, in that specifying a fixed
> > set of alternatives (i.e., a list of color spaces known to CSS), if
> > done right, doesn't limit what developers can do, only how they can
> > do it (which is something language designers limit all the time).
> > If the color spaces specified in CSS can represent the range of
> > colors that developers want to specify, there isn't (I don't think)
> > a loss of capability in forbidding other options.  And there is a
> > gain, in terms of simplicity of the platform and avoiding dealing
> > with the bandwidth and complexity of loading external resources.
> >
> > -David
>
> How exactly do you imagine this working? How many ICC profiles will we alias? Do you have a set in mind that “developers want to specify”? If I want to specify colors with the color profile of my specific monitor, how I will do so? If I want to specify colors that match a specific printer's output, how will I do that?
I'm saying that any single particular color, even if it's outside
sRGB, should be specifiable without browser support for downloading
and processing ICC color profiles.  If you have a particular need to
convert a set of numerical descriptions of colors (described
according to a particular ICC profile) on the client into a form
accepted by the browser, it seems like you could do it with a
javascript library -- and, further, if there were substantial demand
for such a feature, examples of such javascript libraries and how
they behave should be being raised in this discussion.

The issue that seems important to solve in this thread is to make
sure we agree on how we want colors outside of the sRGB gamut to be
specified in CSS.

-David

--
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)

signature.asc (836 bytes) Download Attachment
1234