David: I was reasonably happy with how the blink-dev thread evolved

... I think people eventually agreed that there's more work to be done

... what is the TAG supposed to be doing about this? Fundamentally, lab and lch are simple, except that there's all this color gamut stuff, and I don't know coordination will happen if we don't do it, but I don't know if the TAG is particularly good at that

Peter: It is something we should do, whether or not we're good at it. Who should we reach out to?

David: I'm not entirely sure. I don't completely understand some of the color profile stuff. The other questions are how does it interact with canvas and compositing.

... does it make certain compositing optimizations more observable now?

Tess: I can run this by Simon and Dean

David: we should be making sure that the right people are looking at this

... it would be nice if some of the chromium folks working on this were also doing that

... seems the person working this on the chromium side is new to colors

Peter: are there any other places on the platform where color is exposed

Tess: HTML legacy (color attributes, input element), CSS, SVG, all different canvas contexts (2d, webgl, webgpu), media (video, images)

David: videos may be particularly interesting

Peter: WebXR?

David: the media stuff probably already has a bunch of color space stuff that isn't quite right

Tess: what's the next step here?

David: what are we concerned about? if we ask people to review, what do we want them to keep an eye out for?

... 1a. do you have the ability to specify all the colors you want to specify in this place

... 2. do you get interoperable results (lack of interop could be things like different working color spaces; different clamping to device gamuts; other things)

Peter: at some point things that expose raw bitmap data will want to do something more than 24 bits

David: 1b. so it's not just specify, it's also can you get them out

... another part of 2. making sure we don't create a bunch of corners... avoiding things being "whatever you want" rather than defined... e.g. untagged images in the past (now treated as sRGB). we want to avoid new things like that.

Tess: This plus the list of places to look at earlier create a review matrix

David: another part of 2: the definitions of color-interpolation and color-interpolation-filters properties in svg may have an interesting list of things that could be affected

[rossen returns]

Tess: could design-principles come out of this?

Rossen: this could be a good set of design principles, lots of cross-cutting concerns

David: I'll try to write a comment in the issue, summarizing the conversation we just had, and we should all try to rope in experts to do the review

... maybe Chris Lilley

Tess: when should we push this out to?

[push out two weeks

Alice: would be nice to have a discussion of how you'd choose which one to use.

Alice: also curious if we could see explainers for CSS specs, which would help people who weren't in the meetings understand them. More examples might be useful; conversion description seems very underspecified (no links).

Alice: WCAG specifies color contrast using an algorithm based on YCbCr. Could this be useful in computing color contrast ratio values? Could we give people something that would let them do math on their CSS values for color contrast?

Rossen: ...

Alice: If we can get the computed values in lab() and then map the luminance there to something used in the existing color contrast calculation?

Alice: I could look at comparing lab() lightness ratios with WCAG contrast ratios.

David: equations

Alice: But the main question I don't know: can we get computed values in lab()/lch()/etc.

David: part of a different spec?

Rossen: (looks through w3c/csswg-drafts#4647, then looks for a different issue)

Peter: could be handled by Typed OM, but I don't see anything there about colors at all

David: should we try to come back to this in a week or two?

David: 3 threads of discussion in this issue - one was the one we talked about last week - useful for contrast ratio - we have settled. The other is someone who says lab ^ lch aren't very good. A bunch of people disagree. The third thread is what other parts of the web platform need to be adjusted. Maybe we should bump it...

Dan: maybe close off the first 2...

David: [bumps 2 weeks and leaves a comment]

David: I emailed Chris Lilley, he responded but I haven't processed his response fully yet.

Tess: David wrote a comment two weeks ago... 4 distinct threads of conversation in the issue, main reason was to monitor progress on what other parts of the web platform would need to change.

David: Chris filed 4 issues on w3c/ColorWeb-CG on that.

... We might want to bump this to a longer time interval...

Tess: Why don't we add TAG-tracking labels to all the issues on other specs, and track those issues that way?

Rossen: One other concern... harmonising colours and colour spaces across the platform is definitely important, but the other issue was computed values. Can we request computed values in these colour spaces from the OM? What is the implication on how these colour functions become more useful for things like colour contrast and other a11y features?

Alice: Would be nice to get computed values, but David calculated that the L* value isn't useful for that. Might be worth asking the question directly of whether we could have APIs to get computed luminance directly, although there is work in progress (?) on a new contrast ratio computation. https://github.com/w3c/wcag/issues/695

Rossen: Looking at current state of CSS Typed OM, whether or not we are defining typed colour values in a way that we can provide an API to simply compute the contrast ratio. Currently no, simply mapping to CSS Color (rgba) value.

Alice: Would be nice to be able to provide results of colour math specifically for the purposes of computing contrast ratio, but I think that's mostly orthogonal to this issue. For this issue we're probably alright with just adding trackbacks as Tess suggested, and closing the issue.

Rossen: Not much to talk about here, maybe. Lots of comments on the TAG review issue though.

David: Was trying to encourage getting issues filed against HTML and CSS. https://github.com/w3ctag/design-reviews/issues/488#issuecomment-635010629

Peter: Chris is saying the color on the web CG will file issues as they find them.

David: I think we decided last time we were happy to close this, encouraging the CG to file issues on the relevant WGs sooner rather than later.

Rossen: We discussed figuring out how we can do color contrast in terms of computed values... can we create a Typed OM color object to easily answer some of these questions. Lea mentioned some kind of color space agnostic color object. They are working on trying to release as a library soon-ish.

... Then, how do we standardise color, what is color, getting very philosophical. https://github.com/w3c/css-houdini-drafts/issues/989

... I also recall us discussing closing the TAG issue, allowing progress to continue in the CG, HTML and CSS.

... Main feedback was about the color object, having an API to compare colors. These things are all on their radar.

Alice: How would this work in other parts of the platform, per David's original feedback?

Rossen: Color object will be color space agnostic... can you translate colors outside of the sRGB gamut .. for canvas?

David: CG is doing a bunch of that work. It's more than just canvas - things like filters and interpolation, etc.

dbaron: Possible closing comment:

We're looking at this in a TAG breakout today, and I think we're happy closing this issue at this point, which we propose to do in this week's plenary. We've provided a few pieces of feedback above that seem to have dealt with (see previous summary), or are being actively worked on:

• One of those is the review of sRGB dependencies in other parts of the platform, which it seems the Color on the Web CG is working on. We'd strongly encourage getting those issues filed against the relevant specs sooner rather than later so that the working groups involved can get started on fixing them sooner rather than later.
• Another seems to be the desire for better color conversion APIs, for which a color object proposal seems to be forthcoming