- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 13 Oct 2021 16:24:07 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `OKLab OKLH`, and agreed to the following: * `RESOLVED: Define gamut-mapping using OKLCH and OKLIE` * `RESOLVED: For non-legacy color formats, use OKLAB for interpolation by default (instead of CIE LAB)` * `RESOLVED: Add syntax to represent OKLAB and OKLCH colors` * `RESOLVED: Add oklab() and oklch()` * `RESOLVED: Add these as keywords to color-mix()` * `RESOLVED: Add these to color adjustment functions also` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: OKLab OKLH<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6642<br> <fantasai> Chris: I gave a presentation on this, and documented my reasoning in depth<br> <fantasai> Chris: My first request is, in the gamut-mapping section, we use OKLCH instead of CIELCH<br> <fantasai> Chris: And we use OK delta E instead of ???<br> <fantasai> Chris: Because much less computational complexity<br> <fantasai> Chris: And also much better results in blue/purple region<br> <fantasai> Chris: I otherwise can't produce a good result that I like<br> <fantasai> Chris: I posted some results in the last few comments<br> <florian> q+<br> <fantasai> Chris: You'll need to use ??? because it uses display-3<br> <dbaron> s/???/CIE delta E/<br> <astearns> ack florian<br> <dbaron> (that was for the previous ???)<br> <fantasai> florian: I watched presentation, you made a compelling case<br> <lea> q?<br> <lea> q+<br> <fantasai> florian: The only worry is it's new, and some things maybe need to be discovered<br> <fantasai> florian: But overall seems compelling, including this first point<br> <fantasai> Chris: My thoughts also, which is why I put so much effort into it<br> <astearns> ack lea<br> <fantasai> Chris: IT's also been implemented in various libraries for JS, Python, etc. by now, so have more confidence now<br> <fantasai> lea: I have similar concerns as Florian, but given explanation that we primarily want to use it for gamma-mapping, it's OK<br> <fantasai> lea: ...<br> <fantasai> lea: So see no problem for having this<br> <fantasai> astearns: Is it implemented in any OSes?<br> <fantasai> chris: to my knowledge, no, only in color libraries<br> <fantasai> chris: but it is extremely trivial<br> <fantasai> astearns: so you don't expect objections from implementers?<br> <fantasai> chris: I do not<br> <fantasai> astearns: Anyone with gamut-mapping opinions?<br> <lea> s/lea: .../lea: If authors actually want to use the oklab() or oklch() functions instead of the established lab() and lch() ones, I suppose they have a reason, so I see nothing wrong with it either/<br> <fantasai> astearns: proposed resolution is to use OKLCH and OKLIE for gamut-mapping<br> <fantasai> RESOLVED: Define gamut-mapping using OKLCH and OKLIE<br> <lea> s/lea: I have similar concerns /lea: I had similar concerns /<br> <lea> s/OKLIE/OKLCH/<br> <fantasai> chris: In the interpolation section, currently say that legacy formats interpolate in sRGB and newer formats interpolate by default in CIE LAB<br> <fantasai> chris: would like to change that to OKLAB by default, because it will give better results<br> <fantasai> florian: I support this<br> <TabAtkins> +1 from me<br> <lea> No objection<br> <TabAtkins> "legacy" is anything defined in Color 3<br> <fantasai> smfr: If gradient uses legacy color at one end and non-legacy at the other end<br> <fantasai> lea: fancy new algorithm<br> <fantasai> smfr: spec should say that<br> <fantasai> lea: it does<br> <fantasai> astearns: any other comments?<br> <fantasai> RESOLVED: For non-legacy color formats, use OKLAB for interpolation by default (instead of CIE LAB)<br> <fantasai> chris: This gives us internal ability, but users can't use it<br> <lea> smfr: It is mentioned here: https://www.w3.org/TR/css-color-4/#interpolation-space<br> <fantasai> chris: So suggest to add oklab() and oklce() functions<br> <lea> s/oklce()/oklch()/<br> <fantasai> chris: keeping existing lab() and lch() functions as-is, since people are used to it<br> <fantasai> chris: so question is, should we add this, and also, what syntax?<br> <fantasai> astearns: If we're using interpolation, don't we need to add syntax for it anyway?<br> <lea> +1, if the browser implements it, it makes sense to expose it to authors too<br> <fantasai> to represent colors in the middle of interpolation, e.g.<br> <fantasai> florian: It does make sense to add it<br> <fantasai> florian: Only other possibility would be to use color()<br> <fantasai> chris: color() only takes rectangular forms, not polar form, and polar form is more useful here<br> <fantasai> florian: I support the suggestion, just want to understand alternatives<br> <fantasai> florian: If we add directly as a function, options are lab() and oklab(), or cielab() and lab()<br> <fantasai> florian: Given current tools report (unprefixed) lab as CIE LAB, Chris's suggestion seems to make sense to me<br> <fantasai> astearns: Anyone with concerns adding this at all?<br> <fantasai> +1 to add<br> <argyle> +1 to adding<br> <fantasai> astearns: Proposed resolution is to expose these by some syntax<br> <fantasai> astearns: Any objections?<br> <fantasai> smfr: So if you specify lab() colors, they'll interpret in oklab()? Is that OK?<br> <fantasai> chris: They would unless you ask them to interpolate a different color space<br> <fantasai> lea: We did discuss having two colors interpolate in their shared space, if any<br> <fantasai> lea: but that doesn't work well for RGB formats, because the interpolate badly in RGB<br> <fantasai> chris: In general you should see very similar results<br> <fantasai> astearns: Any other concerns to adding?<br> <fantasai> RESOLVED: Add syntax to represent OKLAB and OKLCH colors<br> <fantasai> astearns: OK, so next question is, do we like the oklab() and oklch() proposed syntax?<br> <fantasai> [silence]<br> <TabAtkins> Sufficiently okay with this. ^_^<br> <argyle> lol<br> <drott> :)<br> <fantasai> RESOLVED: Add oklab() and oklch()<br> <fantasai> chris: Do we add to color-mix()?<br> <fantasai> lea: that should be automatic<br> <fantasai> RESOLVED: Add these as keywords to color-mix()<br> <dbaron> One of the earlier OKLIE -> OKLCH corrections should have been "OKLIE" -> "OK delta E", I think.<br> <fantasai> chris: We have a color adjustment syntax, should be able to do that with OKLAB and OKLCH as well<br> <fantasai> astearns: proposed to add these to ???<br> <argyle> <3 rts, `oklab(from #f0f l a b / 20%)` 👍🏻<br> <fantasai> RESOLVED: Add these to color adjustment functions also<br> <dbaron> s/???/relative color syntax/<br> <fantasai> astearns: fwiw, I would consider the last two reasonable to do under editor's discretion<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6642#issuecomment-942473702 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 13 October 2021 16:24:09 UTC