- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 31 Mar 2021 16:32:46 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-color-5] How should negative percentages behave in color-mix()?`, and agreed to the following: * `RESOLVED: clamp values between 0-100, all other values are invalid` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-color-5] How should negative percentages behave in color-mix()?<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/6047<br> <dael> Rossen_: Do we have right people to proceed?<br> <dael> many: yes<br> <dael> TabAtkins: chris leaverou_ feel free to jump in<br> <leaverou_> q+<br> <dael> TabAtkins: A few weeks ago talked about colormix and grammar. Matching so each color has a % and normalize to 100% if don't sum<br> <leaverou_> q+ ChrisL<br> <dael> TabAtkins: Further question about what should allowed range be. crossfade only allows 0-100 and if you exceed it's invalid. leaverou_ and chris argue allowing other values make sense. Have justification for it that I can't parse. una and I on side of not doing that and matching crossfade<br> <dael> TabAtkins: Arguement is that negative % and greater % don't accord with mixing colors we're trying to define. not intuitive, though mathematical, and would confuse. Also, when normalize to 100%, that is extrodinarily weird with negative %<br> <dael> TabAtkins: You have to grow values to sum to 100% and get very strange large results. redd 100 and blue -100 there's no way to resolve. Sometimes you get sum but multiply by negative to get it. Even if it's well defined the edge cases are very weird.<br> <dael> TabAtkins: leaverou_ and chris have added explinations, but I think they contridict<br> <dael> leaverou_: not sure we should base on crossfade which is something not widely impl. Only 1 or 2 impl and at least WK is not per spec. Not sure why design based on that.<br> <dael> leaverou_: main point is there is a place in css where we color interpolate and allow wider range. In transitions. You can have cubic bezier that's out of range and it does what chris and I advocate<br> <dael> leaverou_: Can look in issue for results, don't think it's unintuitive. If you mix with blue -% you get a less blue color. Blue coord in sRGB is less but hue is less blue which is what matters<br> <dael> leaverou_: If you mix -100% something it's weird, but edge cases that are weird in everything<br> <dael> TabAtkins: What you said is wrong. It doesn't make it less blue. It's dependent on other color. I have an example where -blue + green is more green<br> <dael> chris: we need to avoid saying you are wrong in these discussions.<br> <Rossen_> q?<br> <dael> chris: We're talking abotu a hue angle. not gamma encoded.<br> <dael> TabAtkins: Agree you don't get a hue. I have green + negative blue and you get more green channel<br> <dael> chris: You're looking at gamma encoded channels. Can't do it like that. Look at actual color<br> <dael> TabAtkins: Would you like me to show you color and you can tell me hues<br> <dael> chris: not going to do calc on the fly<br> <miriam> q+<br> <dael> chris: You can't present as leaverou_ and chris have weird idea, color science has this idea. There is a positive case. You get ringing artifacts on the transition. We're not saying great use case for -300%. We're saying sometimes you have slightly over or under. You have line extend out pastt the 2 colors on chromatics.<br> <dael> chris: I get it could be unintuitive, but possible to spec and reasonably useful. I'm fine with clampping 0-100, jsut suboptimal<br> <TabAtkins> I'm ready to respond whenever btw<br> <Rossen_> q?<br> <dael> leaverou_: If we end up not allow they should be invalid. Silent clamp there's no feedback to authors and can't change<br> <dael> Rossen_: Point of order. Convo is lively. chris I appriciate working with tone. I want to discourage blaming and direct language. Let's focus on issue here.<br> <dael> TabAtkins: Real quick, I'm talking about facts here. Casting me as this is technically wrong is being heated is disappointing. I don't want this as TabAtkins is angry because I'm saying the math doesn't back up what you're saying. As far as I can tell my examples show that the math is wrong. I want to focus on that<br> <dael> Rossen_: Let's continue to focus on that math. Leave personas out of discussion<br> <chris> q?<br> <leaverou_> q-<br> <dael> Rossen_: There's 3 folks on the queue. leaverou_ and chris you had taken turns. Are you done?<br> <dael> chris: let's miriam<br> <chris> q-<br> <Rossen_> ack miriam<br> <Rossen_> ack chris<br> <dael> miriam: Reading this from mental model I liked in TabAtkins last comment the sugestion if we want allow negative mix better framed as color interpolation. If we want extending past the mix that would get a new name and syntax. for mixing we would clamp or make invalid numbers above or below 100 or 0<br> <chris> q+<br> <dael> Rossen_: Hearing 2 folks suggesting clamping between 0 and 100 is fine as long as rest of range is handled as invalid<br> <florian> q+<br> <leaverou_> q+<br> <dael> chris: agree. silent clamp we're struck so if restrict have to invalid<br> <Rossen_> ack chris<br> <dael> TabAtkins: agree<br> <Rossen_> ack florian<br> <dael> florian: chris said he won't do color math on fly. Reasonable. If he would do it offline it will show where the math mistake is. Based on that if he disproves one math there's no reason to continue.<br> <dael> TabAtkins: Happy to do that. Have a trivial example with single numbers we can look at and talk about<br> <dael> florian: I would suggest we do it offline. Make sure everyone has math right<br> <dael> chris: If we agree we're on 0-100 only we don't have to care about math for others. We could get a decision. Would be okay with it. We can extend later if needed<br> <dael> Rossen_: I want us to get to a decision. leaverou_ is on queue<br> <dael> leaverou_: Silent clamp or invalid, cubic bezier used to be invalid outside 0-100. I suppose it wasn't deemed useful, realized authors wanted it, and we did it. Making it invalid would allow a similar path<br> <dael> Rossen_: More support to makeing invalid<br> <dael> Rossen_: I heard support from a few folks and TabAtkins saying it's fine, I think<br> <dael> TabAtkins: That's my ideal result. Happy<br> <fantasai> +1 to leaverou_<br> <dael> leaverou_: I'm not suggesting we make it invlid. suboptimal. but invalid is less evil than clamp<br> <dael> Rossen_: and gives a path to make better when we're ready. Instead of continuing to argue on what we're not ready to agree on, we have something we are ready to agree on which gives us path to extend<br> <dael> Rossen_: Prop: clamp values between 0-100, all other values are invalid<br> <dael> Rossen_: Other comments on proposal or objections?<br> <dael> RESOLVED: clamp values between 0-100, all other values are invalid<br> <dael> Rossen_: Rest of discussion is important. Recommend we continue to have this, by way of examples, in the issue when people have time for math<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6047#issuecomment-811218918 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 31 March 2021 16:32:48 UTC