Re: [css-color] wider/deeper colors

> On Mar 22, 2016, at 08:13, Dean Jackson <dino@apple.com> wrote:
> 
> 
>> On Feb 16, 2016, at 11:54 AM, Dean Jackson <dino@apple.com> wrote:
>> 
>>> 
>>> On 17 Feb 2016, at 6:49 AM, Chris Lilley <chris@w3.org> wrote:
>>> 
>>> Hello Tab,
>>> 
>>> Tuesday, February 16, 2016, 7:53:29 PM, you wrote:
>>> 
>>>> On Tue, Feb 16, 2016 at 1:34 AM, Chris Lilley <chris@w3.org> wrote:
>>>>> Do you mean the existing CSS4 color function, or the function that
>>>>> used to be called icc-color?
>>> 
>>>> Dont' worry about the existing CSS4 color() function, it's badly
>>>> designed and I need to overhaul it, and the name isn't necessarily
>>>> claimed.
>>> 
>>> Oh, good to know. (And I agree it is nice functionality but needs
>>> work).
>>> 
>>> OK, I claim color() so we don't have to call it icc-color() and upset
>>> people.
>> 
>> I think we're now settled on color() for the function name, color-gamut
>> for the media-query name, and color-profile for the @rule that links
>> to an ICC profile.
> 
> Step 1: https://github.com/w3c/csswg-drafts/pull/99

Looks like Chris was a bit hasty in merging this. First, only the .bs file was updated, but MQ4 has the output html file committed to the repo as well, so we haven't actually udated the visible spec. Leaving that aside, the proposal looks good to me overall, but it still has issues:

*  We should be explicit about what happens on non rgb devices. Are they still allowed to match if their color space is wide enough (I think that's the right answer), or must they fail the media query regardless? Should the answer be the same for very different color models like CMYK and for similar ones like RGBY?

*  The prose uses the word "display" to describe the output medium. If this is meant to work the same on mediums that are not "displays", such as pieces of paper, we should change the phrasing (I think that's the right answer). If it is not, then we should define what is and isn't a display (is e-ink one?), and say what happens if your output medium isn't one.

*  If the same MQ is supposed to work for RGB, CMYK, RGBY, or grayscale devices, then we may later add values for gamuts in these color models. I think would make it the first range media query to apply to a partially ordered set of values. I don't think this is inherently problematic, but it's new, so we may want to double check the definitions and be ready to add a note explaining. If it is NOT meant to apply to non RGB colors, that should be reflected in the name (rgb-gamut?)

* How evaluation of this MQ in a range context works is a bit unclear.
  - If I read the spec right, 'color-gamut:srgb' means "sRGB or
    thereabout, and possibly more", not "sRGB or thereabout,
    but not more". This implies that "@media (color-gamut:srgb)"
    and "@media (color-gamut >= srgb)" are meant to be the same.
    Is that right?
  - What is "@media (color-gamut > srgb)" supposed to mean (note
    the strict inequality)? Are we requiring that the color gamut
    is at least as large as the next value (p3), or is a gamut
    strictly larger than sRGB but not by much (and therefore not p3)
    supposed to match as well?
  - If a display's gamut is strictly smaller than p3, but pretty
    close to p3 nonetheless, does it match "(color-gamut < p3)"?
    I.e., can "(color-gamut:p3) and (color-gamut < p3)" be true?
  - What is "@media (color-gamut < sRGB)" supposed to do?
    Should it match devices with a gamut narrower than sRGB or
    thereabout, or should it match nothing, because the color-gamut
    MQ has no value smaller than sRGB?
  ...
  As long as the values have the implied "or larger" semantics,
  I think we would make things clearer by dropping support for
  inequalities on this media feature. Or maybe vice versa.

* The meaning of this media query in a boolean context may shift
  depending on how we resolve the questions above. When is
  "@media (color-gamut)" false?
  - If the device is not a visual one (that's for sure)
  - If the device is not a screen (if we keep the "display" phrasing)
  - If the device has a gamut smaller than sRGB (yes, unless we add
    CMYK or grayscale gamuts to the list, changing which is the smallest
    gamut)
  - If the device has a gamut that matches neither sRGB nor p3
    nor rec2020, even if it is large (if the semantics no longer
    imply "or larger" in the values)
  - If the device has a non RGB color model (maybe)

Hopefully we can agree quickly about these. If not, I'll probably add them as inline issues in the spec. That sounds better than reverting until we solve it all.

 - Florian

Received on Tuesday, 22 March 2016 07:26:17 UTC