Re: [css-color] Color issues for F2F discussion

Hi Dean,

The meeting went well and I think we covered most of your points.
Unfortunately, we didn't have enough time to cover them all.

The WG decided to move to github so maybe we need to break your and the
spec issues in separate github issues.

On Wed, May 11, 2016 at 5:36 AM, Dean Jackson <dino@apple.com> wrote:

> [Personal note: it was painful to not spell colour correctly all through
> an email that uses the word so much]
>
> I won't be able to dial in for the discussion of color on Wednesday but
> Simon (smfr) will be there representing Apple (and that's always an
> improvement on me anyway!)
>
> I think there are a few things that could be discussed. If it helps, I've
> numbered everything.
>
> Note that there are a few other parts of the platform trying to solve
> similar issues. For example, there is a discussion about how to specify the
> profile and backing-store depth of an HTML canvas element (
> https://github.com/whatwg/html/issues/299). What we decide has a impact
> there. e.g. the "fillStyle" and "strokeStyle" properties accept CSS colors,
> so will likely be what people use to draw with extended colors.
>
>
> 1. The color-gamut media query [
> https://drafts.csswg.org/mediaqueries-4/#color-gamut]
> ----
>
> WebKit now has an implementation of this, but it currently only works on
> iOS and we don't have public/nightly builds on that platform (sorry). We're
> discussing the best way to implement this on OS X with other engineers.
> Here are some things that we've uncovered:
>
> 1.1 What should happen to the query if the user has set, via the OS, their
> display profile to sRGB when they are on a P3-ish or above display?
>

[didn't discuss this] If the user does this, they probably want to see
over-saturated colors so it should return sRGB.


> 1.2 The query (color-gamut: sRGB) should evaluate as true on nearly all
> modern display hardware. However, it evaluates as false on browsers that
> haven't implemented the query yet. This isn't unusual, but it makes me
> wonder if there is any point in having an sRGB keyword at all, and just let
> the parameter-less version handle that.
>

[didn't discuss this] I agree, this keyword seems unnecessary.


> 1.3 Following on from that, since @supports only takes property:value
> statements, you can't detect if a browser has implemented the color-gamut
> query. This is fine for stylesheets, where you'd just put the conditional
> content inside the @media condition, but it means there isn't any way to
> detect from JavaScript. It would be nice if CSS.supports() had a way to
> detect the implementation. Obviously this isn't specific to color-gamut.
>

[didn't discuss this]


> 1.4 Should we add a "narrow" for displays less than sRGB (or something
> like that)?
>

[we briefly talked about this but I don't remember the conclusion. It's
also not in the minutes]


> 1.5 Florian asked a lot of specific questions on color-gamut. I think he
> intended to add them as inline issues in the spec.
>
>
> 2. Specifying colors outside of sRGB
> ----
>
> I *think* we're mostly in agreement here, but we just need to work out the
> details.
>
> 2.1 Values outside of [0,1] in rgb/rgba. We need to choose a function for
> mapping such values into colors. The two candidates proposed so far are
> scRGB and xvYCC.
>

Chris proposed that over-range colors are no longer allowed for css' RGB
color and people in the room agreed with him.
A user can use Lab colors or a colorspace with a larger gamut.


> 2.2 I think we're still waiting for Adobe to give us feedback on the
> workflow for these situations. Basically, how do people choose colors
> outside their display gamut. (Rik did explain some things in an email
> around 23 March, and I would summarise it to be "there is a document
> profile and everything maps into that" - which is part 3 below)
>

Correct. A user can set the working colorspace with a wide gamut but it is
then reduced when going to screen.
For prepress we offer the author the option to "proof" their output or they
can print to a device that can simulate known profiles. In a publishing
workflow, there's typically a designer with a high-end monitor that can
verify that the colors display as intended.


> 2.3 The new function for specifying a color in a given profile. Candidates
> were "color" and "icc" (at least a few people didn't like "icc", and on 17
> Feb I declared that we'd agreed on "color"). Unless someone objects, let's
> pick "colour". OK, "color".
>

[we discussed this] Everyone agreed on "color"


> 2.4 What are our hardcoded profiles? I don't have strong feelings, other
> than "p3" being one of them.
>

[this was discussed] Chris captured this as
https://drafts.csswg.org/css-color-4/#issue-74843f0f
An issue is that some profiles cost money (p3) or contain trademarks
(AdobeRGB).

People also wanted the option to get profiles if they are already on the
machine.


> 2.5 Should we support external profiles? In the first version of the
> feature? How do we reference them? (Note that CSS has survived without this
> for a while, even though SVG has supported it)
>
> 2.5 If we do support external profiles, what MUST an implementation do if
> the author specifies a color in one? Can it choose to ignore it? (It has to
> be able to do something in the case where it can't fetch the resource)
>

[ we discussed this for a while. It was captured in the minutes and Chris
updated the spec]

2.6 Again, if we support external profiles, should there be a way to simply
> point at an image and say "use whatever that uses"?
>

[we discussed] the group decided not to allow profile extraction from
images. CORS would also have to apply which could be confusing.


> 3. Document profiles
> ----
>
> This is something that came up in one of the very long email threads (I
> think from Rik).
>
> 3.1 Should there be a way to specify a profile for the entire document?
> That would mean all (existing) CSS color rules would use that rather than
> sRGB.
>

[we discussed this] We agreed on specifying a profile for the entire
document and want to follow what Canvas is doing with its compositing
colorspace.
Chris captured the issue:
https://drafts.csswg.org/css-color-4/#issue-30406c93

A potential issue is the linear vs gamma color space. The canvas spec lists
that new spaces should all be linear but we're worried that not every
browser can support this.


> 3.2 Would untagged images follow the same rule?
>

[we didn't discuss this] Yes, we should assume that untagged images are
into the document space.
Moreover, I believe CSS RGB colors should also be in the document profile.
That way "red" really is 100% red


> 3.3 Would ImageData from <canvas> elements also follow?
>

[this is being discussed on the canvas issue tracker]


> 4. Other stuff
> ----
>
> 4.1 There was a request to specify the colorspace used for gradients,
> possibly by extending SVG's color-interpolation property. The request
> explicitly said that the only other option, linear sRGB, isn't good enough.
>

[we discussed this] Gradients are interpolated in the document's
colorspace. There was no mention that linear sRGB wouldn't work (but I
might have missed it)

4.2 The same email mentioned something that's specific to gradients, but we
> might as well discuss it here: should there be a way to request dithering
> of gradients on 8-bit displays? (Personally, I can't imagine any designer
> wanting banding unless they explicitly asked for it)
>

Is there a problem with banding today? An HDR monitor should render with at
least 10 bits per channel which should mitigate issue caused by the higher
gamut.


> 4.3 What about blending? Should there be a way to specify the way colors
> are blended?
>

[we touched upon this] Alpha and color blending blending will work the same
as before.
Chris and Florian wanted Lab as a working space but it implies different
formulas.
For instance, if you multiply Lab(100, -10, 0) with Lab(100, 10, 0), you
don't want Lab(100, -100, 0) as a result.


> 5. Really other stuff
> ----
>
> 5.1 Black point compensation?
>

[we touched upon this] We decided to always have BPC turned on.


> 5.2 High dynamic range images?
>

[we didn't discuss this] What is the issue?


> 5.3 Tagging SVG images?
>

[we didn't discuss this] Inline SVG should follow the document profile.
Maybe we can state that svgsvgelement can specify the CSS property for the
document profile?