Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-color-5] More clarity around the percentage in color-mix() #6064

Closed
mirisuzanne opened this issue Mar 2, 2021 · 11 comments
Closed

[css-color-5] More clarity around the percentage in color-mix() #6064

mirisuzanne opened this issue Mar 2, 2021 · 11 comments
Labels
css-color-5 Color modification

Comments

@mirisuzanne
Copy link
Contributor

The defintition of color-mix() in CSS Colors level 5 includes a <percentage> value for defining the relative weight of the colors being mixed. That weight is given to one of the two colors, with the remaining percentage given to the other color.

From the examples, I can infer that the given weight is used for the first color, and the remaining percentage is applied to the second color – color-mix(red 80% blue in lch) will be 80% red and 20% blue – but I don't think that's clearly stated anywhere. It also seems to contradict this note:

Note: As a corrollary, 0% just returns the first color converted to the specified colorspace, 100% returns the second color converted to the specified colorspace, and 50% produces an equal mix of both.

I would expect that to be the opposite.

  • If we apply 0% of the first color, we should get the second one converted to a given colorspace.
  • If we apply 100% of the first color, we should get that same color, but converted.

(I'm not sure if there's also a way to make this more clear in the syntax, but that's a separate issue. I have to look this up every time I use the Sass function as well. My mind refuses to retain this information…)

@mirisuzanne mirisuzanne added the css-color-5 Color modification label Mar 2, 2021
@LeaVerou
Copy link
Member

LeaVerou commented Mar 2, 2021

Yup, that's an excellent point. The percentage could be interpreted as "X% of the first color" or "X% along the progression". Currently the grammar is written with the first definition in mind (hence why the percentage cannot be after the second color) but the prose describes the second definition.
Perhaps we should make this more clear with syntax (e.g. with an of keyword)

argyleink added a commit to argyleink/csswg-drafts that referenced this issue Mar 2, 2021
@argyleink
Copy link
Contributor

agree that the Note is opposite. I've submitted a PR adjusting the note #6065

thoughts on adding 2 keywords so it's suuuuper clear?..

color-mix(0% of red with blue in lch)
color-mix(100% of red with blue in lch)
color-mix(80% of red with blue in lch)

@Myndex
Copy link
Member

Myndex commented Mar 2, 2021

The following may be tangential to this thread, but:

0% should always have the same result, regardless of linear or the gamma for gamma encoded space.
100% should also.

However 50% should be expected to be very different depending on the gamma or linearness of the space, and just as an FYI, alpha values are affected by the gamma of the color values, so an alpha of 0.5 effectively has a different perceptual effect for different colorspaces, i.e. if you have a color in linear space with an alpha of 0.5, when converting that color to a gamma encoded space, the alpha also needs to be adjusted/converted.

@LeaVerou
Copy link
Member

LeaVerou commented Mar 2, 2021

@Myndex Could you please open another issue and clarify what change you are proposing? As you were previously advised, posting tangentially related issues into other threads means your points are easily lost.

LeaVerou added a commit that referenced this issue Mar 2, 2021
@LeaVerou
Copy link
Member

LeaVerou commented Mar 2, 2021

Note that re-introducing commas can also help readability here, with or without the of keyword (20% of red, white). I've opened an issue about this in #6066

Another thing to resolve on wrt percentages is that perhaps we should allow percentages for either of the colors, instead of only for the first, and specify what happens when both are provided (they are scaled down proportionally, just like border-radius).

@Myndex
Copy link
Member

Myndex commented Mar 3, 2021

@Myndex Could you please open another issue and clarify what change you are proposing? As you were previously advised, posting tangentially related issues into other threads means your points are easily lost.

Hi Lea @LeaVerou Sorry... Not sure what or if what I am saying is relevant as it looks like there are some bigger changes I'm not aware of, I'll try and get more up to speed before spinning wheels.... :)

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed More clarity around the percentage in color-mix(), and agreed to the following:

  • RESOLVED: color-mix(<metadata>, <color-option>#{2}), where <color-option> = <color> && <percentage>?
The full IRC log of that discussion <Rossen_> Topic: More clarity around the percentage in color-mix()
<Rossen_> github: https://github.com//issues/6064
<TabAtkins> gradients use "to" because it disambiguates whether the gradient comes *from* that direction or goes *to* that direction (and we flipped back and forth during dev, so there's no obvious answer).
<fantasai> miriam: In the middle space, single percentage value, and spec was conflicted on what that refers to
<fantasai> miriam: is it percentage color, or distance to second color
<chris> q+
<fantasai> miriam: or percentage of second color
<fantasai> miriam: spec disagreed with itself
<TabAtkins> gradients use "at" to separate the <position> from the possibly-preceding <length>{1,2}
<fantasai> miriam: with commas, would be nice to do percentage in either color
<leaverou> note: the spec has since been fixed and does not disagree with itself anymore :)
<fantasai> miriam: so if you put in first color refers to weight of that color, second is weight of second color
<Rossen_> q?
<leaverou> q+
<fantasai> miriam: would have to decide what to do if 2 percentages are specified
<fantasai> miriam: SASS functions confusing as well, never clear to me which the percent refers to
<TabAtkins> q+
<Rossen_> ack chris
<fantasai> chris: My understanding was % is % of that color, and all examples (there were more examples before)
<fantasai> chris: there was just one sentence that was off, and Adam fixed ti
<fantasai> chris: Seems clear it's a % of that color, not along a blend between the two colors
<fantasai> chris: the color that it's next to
<fantasai> leaverou: mixing paints, makes sense % of first color
<fantasai> chris: ... that's confusign
<fantasai> chris: if % don't add up, scale to add to 100%
<fantasai> chris: does that make sense?
<fantasai> miriam: So % goes with a color between the commas, that makes sense to me
<fantasai> miriam: so % can be applied to either color, and can put it in one or both
<fantasai> leaverou: Should allow for ...
<fantasai> leaverou: and scale accordingly
<fantasai> chris: Have that in HWB, if too high scale it back
<Rossen_> ack leaverou
<fantasai> TabAtkins: I think whichever syntax we go with, should be consistent between color-mix() and cross-fade()
<fantasai> +1
<fantasai> TabAtkins: cross-fade() matches up with what miriam suggests
<fantasai> TabAtkins: can add % with any of the images
<fantasai> TabAtkins: whichever one, if omitted, it's just 100% - [sum]
<fantasai> TabAtkins: if don't add up to 100%, we fill in the remainder with a transparent image
<Rossen_> ack TabAtkins
<fantasai> TabAtkins: idk if we want to do with colors
<chris> prefer a rebalance like HWB
<fantasai> leaverou: 3-way mixes are confusing, too many ways to do it
<fantasai> TabAtkins: I agree with reasoning for not doing 3-color mixes, but adding in transparency doesn't suffer from same confusion issues
<fantasai> TabAtkins: not strong on either, but greater consistency with cross-fade() would be good
<Rossen_> q?
<TabAtkins> chris, note that HWB does *not* rebalance for <100% sum
<TabAtkins> there it takes the remainder from the pure hue
<TabAtkins> >100% causing rescaling is uncontroversial and common between all the functions, yes
<leaverou> q+
<fantasai> Rossen_: Can someone summarize the proposed resolution?
<fantasai> leaverou: Before we summarize, one last point
<TabAtkins> Proposed new grammar: color-mix(<metadata>, <color-option>#{2}), where <color-option> = <color> && <percentage>?
<fantasai> leaverou: if we handle percentages < 100% by mixing with transparent, it has special interpolation handling so [????]
<leaverou> s/[????]/we don't want to do that/
<chris> q+ for the negative percentages
<fantasai> TabAtkins: Ignoring the < 100% sum and take it to the issue, think we can resolve on the rest
<argyle> `color-mix(in lch red 80%, blue)` also `color-mix(in lch, red, blue 80%)`
<argyle> `color-mix(in lch, red 80%, blue)` also `color-mix(in lch, red, blue 80%)`
<fantasai> TabAtkins: proposal above
<fantasai> TabAtkins: if above 100%, rescale to add to 100%
<TabAtkins> if below 100%, figure out in issue
<fantasai> Rossen_: any objections?
<fantasai> RESOLVED: color-mix(<metadata>, <color-option>#{2}), where <color-option> = <color> && <percentage>?

@tabatkins
Copy link
Member

leaverou: if we handle percentages < 100% by mixing with transparent, it has special interpolation handling so [????]
s/[????]/we don't want to do that/

Heya @LeaVerou, could you explain what you mean here?

@LeaVerou
Copy link
Member

LeaVerou commented Mar 6, 2021

That was my mistake, it's two legacy colors interpolating that have the legacy behavior, not one legacy color interpolating with a non-legacy color.
Also, legacy interpolation happens when the host syntax does not define the interpolation space, and we just made it mandatory for color-mix() to specify the interpolation space, so that's yet another reason why this doesn't apply.

@tabatkins
Copy link
Member

Ah, k, so does that imply that we could meaningfully mix together transparent and two other arbitrary colors in any of our defined colorspaces?

@svgeesus
Copy link
Contributor

svgeesus commented Jul 5, 2021

I think previous edits have ow resolved this. Lea clarified the grammar so that the color and the percentage of that color are clearly grouped; Adam edited the "corrollary" note so it no longer contradicts the grammar.

If we apply 0% of the first color, we should get the second one converted to a given colorspace.

If we apply 100% of the first color, we should get that same color, but converted.

This is now explicitly stated.

@svgeesus svgeesus closed this as completed Jul 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-color-5 Color modification
Projects
None yet
Development

No branches or pull requests

7 participants