Re: [css-color] wider/deeper colors

On Mon, Mar 21, 2016 at 2:34 PM, Dean Jackson <dino@apple.com> wrote:

>
> On Mar 21, 2016, at 2:19 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
>
> > - media queries to detect different screens so you can special case
>> content
>>
>> Yes.
>>
>> > - be able to specify out-of-range colors
>>
>> Out of what range? color() will allow you to specify colors in something
>> other than the sRGB space, which is your only option at the moment.
>
>
> I'm unsure if it's a good idea to allow the profile right in the color
> definition.
>
> For my own experience, PDF allows this but it's a very problematic
> workflow; mainly because things get complicated really fast.
> We now go out of our way to avoid creating content that uses this feature.
> For instance, Illustrator and Photoshop make you choose a single profile
> and just create colors in that space (regardless of what you see in the
> UI). InDesign still supports this but you have to go deep in the advanced
> settings to turn it on.
>
>
> I'm not sure there is a better workflow for the Web. The other option
> would be to request a colorspace for the entire document and have media
> queries that isolate sections of the styling if the browser supports that,
> and then the typical rgb function would use 0-1 values in the colorspace.
>

I'm not sure why it needs to be a working space for the entire document
(although that is the most common use case).
It could be a new CSS property, for instance: compositing-space:
"p3"/"sRGB"/"uncalibrated"/url(..)
Gamut-selecting media queries would still be allowed and based on the
attached display.


> But the developer is probably going to want to do that based on whether
> the device supports wider gamut, so it would cause multiple nesting.
>

Let's take an example of a developer creating an SVG in Illustrator who is
using a wide gamut iMac. Since he wants to use all the available colors, he
sets the document space to the monitor profile.
However regardless of the profile selected, the generated values in the SVG
stay the same, so there needs to be a way to tag the SVG document profile
as p3.

With your proposal, each color will have include a reference to the "p3"
profile. This is cumbersome but will work, as long as there is no alpha or
color blending or filters.
However, if you tag the inline SVG with the css property:
   compositing-space: "p3"
the document will look correct on a p3 or higher display and as good as
possible on a lesser display.


> I don't want to make this too complicated.
>

>From my experience, authors find it easier to deal with a document color
space than specifying colorspaces in the content.
For instance, originally InDesign encouraged a mixed content workflow but
designers found it almost impossible to use.


> I doubt that people are going to want to specify a huge number of colors
> by hand that are outside sRGB, in the near future at least. It's more
> likely going to be something like this:
>
> :root {
>   --my-color: rgb(255, 0, 0);
> }
>
> @media (color-gamut: p3) {
>  :root {
>      --my-color: color(p3, 100%, 0%, 0%);
>   }
> }
>
> Then var(--my-color) will be the brightest red on the display.
>

Only if you have a p3 display or one that matches sRGB.
What happens if someone releases a display with an even higher gamut than
p3 or one that is close but not the same (like AdobeRGB)? Do pages have to
be redesigned to select the p3 media query?

If the intent is to create consistent color, it seems that this is
accomplishing the opposite. Maybe I'm missing something...