- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Jun 2022 16:51:16 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-color-5] Clarify serialization of color-mix()`, and agreed to the following: * `RESOLVED: color-mix() returns color() for sRGB mixes` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: [css-color-5] Clarify serialization of color-mix()<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6206<br> <bradk> I just shared a rendering that I **think** is what fantasai was proposing<br> <bradk> Shared in WebEx<br> <fantasai> chris: agreement in general, remaining issue is should things like hsl come out as themselves, come out as rgb, or use the color() function which retains more precision<br> <bradk> Ok<br> <fantasai> chris: Emilio said it would be harder to ship, but could see the value of it, so not sure where we are on that<br> <fantasai> emilio: That's still my opinion<br> <fantasai> emilio: slight preference to serialize as input color<br> <fantasai> chris: I can see arguments both ways<br> <fantasai> chris: I have a slight preference for serializing as color()<br> <fantasai> jensimmons: any visual difference in the result?<br> <fantasai> chris: there could be, but very slight<br> <fantasai> chris: if only 8-bit, and do mix of a mix, lose some precision and could result in banding<br> <fantasai> emilio: that's also an implementation detail<br> <fantasai> emilio: no reason why colors can't be more precise than 8-bit<br> <fantasai> chris: that's not what implementations do<br> <fantasai> chris: spec mandates are higher precision for newer color spaces<br> <fantasai> chris: of course can implement at higher precision<br> <fantasai> chris: but concerned we'll get some degradataion<br> <fantasai> jensimmons: screens are getting better, and color precision going better, seems we should go with higher precision<br> <astearns> ack fantasai<br> <chris> qq+<br> <emilio> fantasai: can be confusing to give two hsl colors and get a different color<br> <emilio> ... from the precision argument I don't see why we won't just encourage implementations to have more precision<br> <astearns> ack chris<br> <Zakim> chris, you wanted to react to fantasai<br> <emilio> ... I don't understand why you'd have different precision on color() vs rgb()<br> <fantasai> chris: not just giving two colors, you specified color space to mix in and you get back in that color space<br> <fantasai> chris: shouldn't be that surprising<br> <emilio> q+<br> <fantasai> chris: wrt precision, implementations have been stuck on 8-bit for a long time<br> <fantasai> chris: but we've also written for other color spaces need 10-bit or 12-bit, or 16-bit for xyz<br> <fantasai> chris: so implementations going into those color spaces need more precision<br> <fantasai> chris: we did say that if you're giving a 0255 value in rgb you can get ?? when you serialize<br> <astearns> s/??/decimal places/<br> <fantasai> chris: but saying hope that everyone upgrades from 8-bit... harder than requiring upgrade for new stuff<br> <fantasai> emilio: I agree with fantasai<br> <fantasai> emilio: we use 8-bit colors for space-efficiency<br> <fantasai> emilio: so you can store an RGB color in one integer<br> <fantasai> emilio: but if we need more precision for htis feature, we can increase<br> <fantasai> emilio: if we implement high-precision sRGB we would do it both for color() and rgb()<br> <fantasai> emilio: there's no point in having two different representations for the same color space<br> <fantasai> astearns: just having higher precision for rgb() and color() wouldn't be sufficient, because color() can give you color spaces that are higher precision<br> <fantasai> fantasai: if I mix 2 rgb colors in xyz space, do I get a color in rgb or xyz space?<br> <fantasai> chris: xyz space<br> <fantasai> faceless: if I mix 2 rgb colors in rgb space, I get rgb space back right?<br> <fantasai> chris: yes<br> <fantasai> s/faceless/fantasai/<br> <fantasai> [missed]<br> <fantasai> astearns: so that you can plug that function into a nother property and not lose precision<br> <emilio> q+<br> <astearns> ack emilio<br> <fantasai> fantasai: if color(rgb) has a particular precision, no reason for rgb() to have different precision<br> <fantasai> emilio: ...<br> <fantasai> emilio: given you need to return a color in ?? color space, I don't think it we serialize as color() or rgb()<br> <lea> q?<br> <fantasai> emilio: maybe color() is more consistent with other colorspace outputs?<br> <lea> q+<br> <lea> q-<br> <fantasai> emilio: I'd be fine serializing as color() if easier for e.g. WebKit, for us it would be the same<br> <fantasai> astearns: I'm hearing a lot of, yeah, either way is fine I gues<br> <fantasai> astearns: so should we pick serializing as a color() function?<br> <fantasai> chris: you're going to get color() function anyway in any of the other color spaces<br> <fantasai> chris: if you just happen to pick srgb, need to pick what to do there<br> <fantasai> chris: imho more consistent to say get a color() function back<br> <fantasai> astearns: so proposed resolution is to serialize as a color() function<br> <chris> +1<br> <fantasai> lea: It's not always [missed]<br> <fantasai> lea: it's not always possible to serialize everything as color() function, there are functions only available in their own function e.g. lab() lch()<br> <fantasai> chris: That's true, but you won't see them in rgb() form either<br> <emilio> q+<br> <fantasai> lea: so does proposed resolution affect only mixing in rgb()?<br> <fantasai> lea: because right now that is the only color available both in functional notation and a color() function, and these are distinct color formats<br> <fantasai> lea: color() function has 10-bit and I think it can go beyond the 0-1 range<br> <fantasai> lea: I'm not sure if browsers want to use 10-bit format every time someone mixes in sRGB<br> <fantasai> lea: want to get clarity if this resolution is only about sRGB or about every color space ... which is not even possible<br> <fantasai> chris: If you choose to mix in sRGB then you'll get in sRGB color space<br> <fantasai> lea: so interpolation token in sRGB, then ?? interchangeable?<br> <fantasai> lea: does the syntax allow both?<br> <astearns> s/??/interpolation token/<br> <fantasai> lea: You specify which color space you interpolate is "in <colorspace>", in gradients or color-mix() or whatever<br> <fantasai> lea: does that mean that "in rgb" is same as "in sRGB" ?<br> <fantasai> chris: you can't say "in rgb"<br> <fantasai> chris: we don't have a color space called "rgb"<br> <fantasai> lea: are you sure?<br> <fantasai> chris: yes<br> <fantasai> -> https://www.w3.org/TR/css-color-4/<br> <astearns> ack emilio<br> <fantasai> emilio: is there any good reason why lab colors can't be specified in color() notation?<br> <fantasai> chris: because color() started out as predefined rgb spaces<br> <fantasai> chris: it's a lot shorter for lab/lch to have their own functions<br> <fantasai> chris: we do have an open issue about throwing everything into color() function<br> <fantasai> chris: but that would just take existing syntax and make it longer<br> <fantasai> emilio: benefit is that color-mix() would have consistent output<br> <fantasai> jensimmons: want to get through these issues so can start shipping<br> <fantasai> astearns: proposed resolution is that we serialize as a color() function for color-mix that is being mixed in rgb<br> <fantasai> lea: no rgb, only sRGB, so makes sense to return color()<br> <fantasai> astearns: any objections to this resolution?<br> <fantasai> RESOLVED: color-mix() returns color() for sRGB mixes<br> <chris> q+<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6206#issuecomment-1156709070 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 June 2022 16:51:17 UTC