- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Jun 2019 18:41:59 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Color Stuff`, and agreed to the following: * `RESOLVED: Put all the proposals into css-color-5, ChrisL and future Una as editors` * `RESOLVED: Rename to put 'color' first, adjust-color -> color-mod()` * `RESOLVED: Add color-contrast() without currentbg` * `RESOLVED: Add color-mix(), try to align with cross-fade()` * `RESOLVED: Put both color adjustment proposals into css-color-5, with keywords instead of css-color-5` * `RESOLVED: Add Lea Verou as editor of css-color-5` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Color Stuff<br> <AmeliaBR> s/Color Stuff/Color modification functions/<br> <chris> github: https://github.com/w3c/csswg-drafts/issues/3187<br> <fantasai> una: Chatting with TabAtkins and my team about color modification b/c very highly requested<br> <fantasai> una: Used a lot in preprocessors<br> <AmeliaBR> Una's proposal: https://gist.github.com/una/edcfa0d3600e0b89b2ebf266bf549721<br> <fantasai> una: Very common pattern, so wanted to revisit as native CSS<br> <fantasai> una: Here's a proposal for a more simplified proposal<br> <fantasai> una: based on three functions<br> <fantasai> una: adjust-color(), mix-color(), and contrast-color()<br> <fantasai> una: color adjustment is basic modification via hcl values<br> <fantasai> una: first arg is color to adjust, then list of modification functions<br> <fantasai> una: mix-color mixes two colors<br> <fantasai> una: contrast-color, submit a bgcolor and then list of color values<br> <fantasai> una: that you would place as text and background, and picks the highest contrasted color<br> <fantasai> una: HCL would be default color space<br> <fantasai> una: can also have color space argument<br> <fantasai> una: lightness in LCH vs HSL<br> <fantasai> una: If using lightness in a color space in e.g. cmyk, then do transformation in LCH and then clipped to CMYK range<br> <fantasai> una: Wanted to make easy to use<br> <fantasai> chris: Like picking LCH by default because it ... gamut<br> <fantasai> chris: result will always be a color<br> <fantasai> chris: like that it's explicit about color space<br> <fantasai> chris: Does mix up in what color space doing calc and what you revert to<br> <fantasai> chris: Gave some comments on this<br> <fantasai> chris: slightly concerned that ppl will believe that lightness = bright ness and chroma = saturation<br> <fantasai> chris: Need to understand that ...<br> <fantasai> chris: Like that we have mixing colors, pretty convenient<br> <fantasai> chris: I do this often by putting colors on a gradient to find a color in between<br> <fantasai> chris: Unsure about ...<br> <fantasai> chris: Contrast color, I like that. Saw ppl asking for conrast things<br> <fantasai> chris: But often they're asking for ...<br> <fantasai> chris: Finding most contrasty color is nice<br> <fantasai> chris: ....<br> <fantasai> chris: I do like the idea of having a thing called currentBackground that we can use elsewhere<br> <fantasai> chris: Lea points out that once you have opacity, you have ranges of contrasts<br> <tantek> currentbgcolor<br> <astearns> s/unsure about .../unsure about mixing by component/<br> <fantasai> leaverou: What do you do about ranges that are overlapping?<br> <fantasai> una: Transparency issue is still unsolved by dev tools and a11y<br> <fantasai> una: so don't know how best to handle that<br> <fantasai> una: but still creating contrast checkers in devtools and other things, can re-use technology<br> <fantasai> una: pick best color<br> <fantasai> una: up to author to make sure it contrasts enough<br> <fantasai> leaverou: not deal breaker, many ways to specify<br> <fantasai> leaverou: just something that needs to be addressed<br> <AmeliaBR> s/asking for .../asking for the ability to tweak their preferred color to meet minimum contrast requirements/<br> <fantasai> una: background with rgba have a difficulty<br> <fantasai> leaverou: can also have semitransparent text, though<br> <heycam> q+<br> <fantasai> chris: I think it's an interesting proposal<br> <fantasai> chris: lots of details to tweak, but overall it's nice<br> <Rossen_> q?<br> <fantasai> chris: also clamping needs to be defined<br> <fremy> q+<br> <fantasai> chris: ...<br> <fantasai> una: I think we could .. with filter now, brightness/saturation<br> <fantasai> una: I like unclamped<br> <fantasai> una: can use value of 1000<br> <fantasai> una: creates interesting effects in CSS that wouldn't otherwise be possible<br> <fantasai> chris: Clamping should be done at last possible moment<br> <chris> q?<br> <fantasai> leaverou: Let's discuss other proposal too so that we can compare. Might end up with blend of both<br> <astearns> ack heycam<br> <fantasai> heycam: overall I like the idaea of color adjustment things<br> <fantasai> heycam: one comment about syntax for mix-color, for images we have the cross-fade function<br> <fantasai> heycam: so if we only want one axis of interpolation, should aign the syntax wth that<br> <fantasai> heycam: this kind of liear interpolation is something ppl want for other numeric tpes as well<br> <fantasai> heycam: e.g. interpolation of lenghts<br> <fantasai> heycam: so maybe generic way for different types, or separate thing for color<br> <fantasai> TabAtkins: We have outstanding rsolution for generic interpolate() function<br> <fantasai> TabAtkins: but mix-color can do more than simple interpolate<br> <fantasai> TabAtkins: mix-color can mix different aspects of the color, pay attention to opacity or not, so much more complicated than other tpes<br> <fantasai> AmeliaBR: For mix-color, heycam talking about cmparison with cross-fade<br> <fantasai> AmeliaBR: A comparison I think of is blend-modes<br> <fantasai> AmeliaBR: The efault mixture of two colors is equivalent ot normal blend more<br> <fantasai> AmeliaBR: to exten there's a % adjustment, that's adjusting opacity of the top blend layer<br> <fantasai> AmeliaBR: Instead of talking about blending two colors using certian channels, maybe mixing using different blend modes is a way to go<br> <fantasai> AmeliaBR: But general rule is re-use existing concepts in CSS as much as possible<br> <fantasai> una: really like idea of thinking as blend modes<br> <fantasai> una: agree that re-using concepts can be nice here<br> <astearns> ack fremy<br> <chris> s/asking for .../asking for a 4.5:1 ratio to pass WCAG/<br> <fantasai> fremy: I was wondering about the color-conrast function<br> <fantasai> fremy: mainly I'm trying to understand how to use in application<br> <fantasai> una: Used for a11y if you have reusable elements<br> <fantasai> una: or dark mode<br> <fantasai> una: if you switch from light pink bg to dark purple bg<br> <fantasai> una: need to ensure conrast<br> <fantasai> una: only have to specify colors one time<br> <fantasai> una: it'll update the color on top of the background<br> <fantasai> una: common thing from SASS that ppl love<br> <fantasai> TabAtkins: crude example here: text is black or white depending on bg in this color palette<br> <fantasai> leaverou: use case right there on github with labels, can give your labels custom bg colors, and GH picks text color to contrast sufficiently -- automatically do that with contrast-color()<br> <fantasai> fremy: Now I understand the use case, label use case is very clear<br> <fantasai> AmeliaBR: One thing about the way una describe diferent from conrast function previously<br> <fantasai> AmeliaBR: previous contrast function, you gave a fixed color and a 2nd color and then a desired contrast ratio<br> <fantasai> AmeliaBR: and it adjusted 2nd color to meet the contrast ratio<br> <fantasai> AmeliaBR: As I understand deciding the correct math for that wasn't satisfactory<br> <fantasai> AmeliaBR: Una's proposal the website author has to give a palette list<br> <fantasai> AmeliaBR: would just select best contrast from list instead of calculating adjustments<br> <fantasai> AmeliaBR: could default to black/white<br> <fantasai> chris: Advantage is end up with a color provided by author rather than random color<br> <fantasai> leaverou presents alternate proposal<br> <una> https://github.com/w3c/csswg-drafts/issues/3187#issuecomment-499126198<br> <leaverou> https://github.com/w3c/csswg-drafts/issues/3187#issuecomment-499126198<br> <fantasai> leaverou: this is just about color adjustment<br> <fantasai> leaverou: problem with color-mod was it only worked in rgb<br> <fantasai> leaverou: Nowadays ppl use ? gamma monitors<br> <AmeliaBR> s/? gamma/wide gamut/<br> <fantasai> leaverou: ppl use terrible hacks by putting things into different variables and stringing together and stuff<br> <fantasai> leaverou: They've used ? in PostCSS, implemented in custom scripts, etc.<br> <fantasai> leaverou: Really need to settle on something whether this or Una's proposal<br> <fantasai> leaverou: THis proposal is based on fact that we have a number of color functions<br> <astearns> s/used ?/used color-mod()/<br> <fantasai> leaverou: besides rgb() and hsl(), also have lab() and ?<br> <AmeliaBR> +100 to we need color modification functions (of some syntax)!!!<br> <fantasai> leaverou: Every color adjustment can be described as djusting channels on one of those functions<br> <fantasai> leaverou: Instead of creating colors, augment by introducing a coor argument on each of them<br> <fantasai> leaverou: so either set coordinates specifically or use calc()<br> <fantasai> leaverou: could also use an underscore to say that this component stays the same<br> <fantasai> leaverou: so making lighter, use lch, multiply lightness by 1.2 would make it lighter<br> <fantasai> leaverou: benefit of this is that every color function gives us extra djusters for free<br> <fantasai> leaverou: Easy to understand b/c uses existing color functions<br> <fantasai> leaverou: Let's say you have cmyk() space, comes with its own adjusters<br> <fantasai> leaverou: also allows adjusting alpha<br> <fantasai> leaverou: re-uses existing syntax, the adjustment just uses calc()<br> <fantasai> leaverou: obivous what the math is<br> <fantasai> leaverou: Drawback is that it might give authors too much rope<br> <fantasai> leaverou: they might just use hsl because familiar<br> <fantasai> leaverou: Una's proposal uses lch(), which does the right thing by default<br> <fantasai> leaverou: but worries me, e.g. doesn't have alpha<br> <fantasai> leaverou: what more is it missing, that we need to add?<br> <fantasai> leaverou: if we add 10 different keywords, then gets too big<br> <fantasai> leaverou: the only benefit is very clear what the target color space is<br> <fantasai> leaverou: Obvious when you convert colors<br> <fantasai> leaverou: clear what's going on<br> <fantasai> leaverou: but it's also more complex<br> <fantasai> leaverou: clarity comes at a cost<br> <fantasai> chris: I like being explicit about the color space of computation and result<br> <fantasai> chris: converting from starting not hard<br> <fantasai> chris: _ is awkward, but might be familiar to ppl using SASS etc, where they construct the result bit by bit<br> <fantasai> chris: Also like using calc()<br> <fantasai> chris: You could do all sorts of interesting things with calc(), so that's astrength<br> <fantasai> chris: if we do get on to cmyk and 7-color printing, hexachrome<br> <fantasai> chris: we don't have to invent new things<br> <fantasai> chris: we just get them for free because it's whatever position it is in the synta already<br> <fantasai> chris: but...<br> <fantasai> chris: Una's proposal does 3 things and each function<br> <fantasai> chris: Your proposal does only one thing, doesn't do the other two<br> <fantasai> chris: The color functions become extremely complicated syntactically<br> <fantasai> chris: First thought was I didn't like this because looked complicated<br> <fantasai> chris: I would like to dive more into what serialization is<br> <fantasai> chris: in general need to understand what serialization is and what's stored in DOM<br> <fantasai> chris: Right now colors are stored as sRGB and that's it<br> <fantasai> chris: Everyone that's seen the color spec, yeah this is good, have LCH and ICC colors<br> <fantasai> chris: high dynamic range etc. solved problem, doing this the right way<br> <fantasai> chris: But interested in how browsers are going to add this<br> <fantasai> chris: So would like to hear comments from implementers<br> <fantasai> chris: Both of these also depend on existing color functions, so need implementers to comment on that too<br> <fantasai> leaverou: both of these would require implementation of LCH<br> <fantasai> AmeliaBR: Do any browsers have work on the way to implement more advanced color spaces?<br> <fantasai> TabAtkins: Don't have work on it, but also LCH is only matrix-math different from sRGB, so not hard, just need some engineering time<br> <fantasai> chris: All the matrix math is in the spec<br> <fantasai> chris: also don't have to implement it like that, can also use ICC or color sync<br> <fantasai> chris: does all that as well<br> <fantasai> AmeliaBR: Lea's syntax can be implemented in parallell, since still get adjustments on rgb and hcl, just that the best artistic results come from lab or lch<br> <fantasai> leaverou: If HSL adjuster is implemented first and then LCH later, then more likely that existing designers will use HSL even though it's not as good<br> <fantasai> fremy: well it works for them<br> <fantasai> chris: It works for them because it's the only tool they have<br> <fantasai> TabAtkins: If you have boht, there's no reason to use HSL, LCH is wayyyy better<br> <fantasai> TabAtkins: Only reason to include older worse ones is compatibility with existing color systems<br> <fantasai> TabAtkins: but want to make using the good function the easy pasth<br> <myles_> q+<br> <fantasai> TabAtkins: so ppl use it and get happy results<br> <fremy> (to correct the notes, I just said that if designers end up using it, that means it worked for them, if the result isn't good enough, they can learn how to improve)<br> <fantasai> una: Problem with Lea's proposal is harder to understand what's going on<br> <fantasai> una: Harder to follow what's happening<br> <fantasai> una: Taking concepts of ?, transformation space, and output clipping<br> <fantasai> una: then build on that<br> <fantasai> leaverou: That's what I was wondering about as well<br> <fantasai> leaverou: ? lightness and hue cover a large percentage of cases. Unsure about individual color channels<br> <fantasai> leaverou: SASS has these, wondering if we can get usage stats<br> <fantasai> leaverou: See how many ppl need them and what use cases are<br> <una> s/concepts of ?/concepts of color space transform + set clipping space<br> <fantasai> leaverou: most use cases I've come across are saturation and lighness<br> <una> s / concepts of ?/concepts of color space transform + set clipping space /<br> <astearns> ack myles_<br> <fantasai> chris: Making a color "more green" is a bit straightforward in rgb, but going towards blue-gree... makes more sense to give a target color and go closer to that<br> <fantasai> chris: Myles, you're building on top of ColorSync, would be interested in what would be hard to do easy to do etc.<br> <fantasai> myles_: not prepared to answer that<br> <fantasai> leaverou: Issue with 2nd one beign underscores, could be some keyword or whatever.<br> <fantasai> leaverou: was an underscore only beause avoids conflicts within color function<br> <fantasai> astearns: Anyone from implementers with enough color experience?<br> <fantasai> AmeliaBR: Reminder that use cases for color modicifcation is increasing steadily<br> <fantasai> AmeliaBR: FIrst with custom properties<br> <fantasai> AmeliaBR: You can't do it in the preprocessor, has to be in the browser to work with dynamic colors<br> <fantasai> AmeliaBR: going into dark mode and using system colors, don't have concrete color to manipulate<br> <fantasai> AmeliaBR: need to do dynamically in the browser<br> <fantasai> una: contrast-color important for dark mode especially<br> <fantasai> una: these work hand in hand with changing technology being implemented in browsers now<br> <fantasai> heycam: One other syntax comment -<br> <fantasai> heycam: In 1st proposal, have adjust-color(), but we have a color-adjust property...<br> <fantasai> AmeliaBR: Could go back to color-mod()<br> <fantasai> TabAtkins: Also switch it to color-mix()<br> <fantasai> ?: And color-contrast() to match<br> <fantasai> astearns: Comment about Una's proposal requiring LCH ...<br> <fantasai> astearns: ...<br> <AmeliaBR> s/?/heycam/<br> <fantasai> astearns: Want to reserve the default for LCH, require a color space until LCH is around, then allow that to be dropped<br> <fantasai> TabAtkins: I object<br> <fantasai> TabAtkins: I don't think the LCH part is the engineering blocker<br> <fantasai> TabAtkins: They're both relatively easy thing that just need effrot<br> <fantasai> TabAtkins: getting it right the first time<br> <fantasai> TabAtkins: if someone wants to impelment adjust-color(), then doing LCH also isn't hard<br> <fantasai> dbaron: Implementing color modification functions seems significantly mroe work than implementing LCH<br> <fantasai> markus: ... Adjustment of image color<br> <myles> q+<br> <fantasai> chris: Ther'es a longrunning FF bug about ICC and imgaes, maybe just for raster images?<br> <fantasai> Markus: ? is working on image color adjustment<br> <fantasai> TabAtkins: Handling profiles but not anything else... so outputting rgb as monitor color space?<br> <fantasai> chris: Can see the difference on my screen, Chrome really gives you the desaturation , Firefox ...<br> <fantasai> heycam: Since we don't color adjust CSS colors, which aspects of these proposals would not be possible ?<br> <fantasai> TabAtkins: none, just do the math<br> <fantasai> TabAtkins: If you have badly-adjusted colors mixed with other colors<br> <fantasai> TabAtkins: In a consistent color space, get better colors later<br> <fantasai> Markus: Nothing hard in the spec from my perspective<br> <fantasai> markus: Hard part is Firefox doing color management in the first place<br> <TabAtkins> s/mixed with other colors/mixed with other colors, you have a problem, but/<br> <fantasai> markus: I don't know about parsing / serialization, but in terms of spec hard part is just finding the right syntax<br> <fantasai> AmeliaBR: Rendering resulting color is a separate, but result of these functions is going to be another oclor function using exisitng color function syntax<br> <fantasai> AmeliaBR: question of what do we do about Browsers trying to squish color functiosn into hex codes when requesting coptued style<br> <fantasai> AmeliaBR: but that's an issue with all advanced gamut<br> <fantasai> chris: It's even an issue with sRGB<br> <AmeliaBR> s/gamut/gamut color functions/<br> <fantasai> chris: If you go into wide gamut or high gamut, not enough storag<br> <chris> q?<br> <AmeliaBR> s/storag/storage/<br> <chris> ack myles<br> <mstange> q+<br> <fantasai> leaverou: Tab, you said that colors mixed being in same color space... do you mena can't mix colors from different spaces?<br> <fantasai> TabAtkins: When mixing colors from differnet spaces and no color managing<br> <fantasai> TabAtkins: Then colors that look like they match won't later once you fix<br> <fantasai> TabAtkins: but if define the mixing color space then it's OK<br> <fantasai> AmeliaBR: If you have an imge that uses a color properly calibrated red<br> <fantasai> AmeliaBR: andyou have an uncalibrated red in your CSS, then your color scheme will look bad<br> <fantasai> TabAtkins: Used to be that RGB 255,0,0 in an image could look dfferent from red in CSS<br> <fantasai> dbaron: depending on whether image had color profiel data<br> <fantasai> una: You can mix colors from different spaces, have to speicfy mixing color space<br> <fantasai> leaverou: Would be nice to have defaults so that you don't have to speficy if you don't want to<br> <fantasai> leaverou: e.g. default to LAB<br> <fantasai> leaverou: if they're not in the same space<br> <fantasai> TabAtkins: One aspect of mixing proposal is nice to mix a single channel<br> <fantasai> TabAtkins: NOt directly interpolation<br> <fantasai> chris: That is an advantage of Una's proposal<br> <fantasai> chris: You could have a profoto RGB color and an adobe RGB color and ????<br> <TabAtkins> s/????/mix the lightness of them, which neither color space has/<br> <fantasai> myles: In first propsoal, contrast-color is different from first two otpions<br> <fantasai> myles: contrast-coor might be unimplementable depending on composting and how far back you have to go back through to find the bg color<br> <fantasai> myles: and if you don't punch through, kinda useless<br> <fantasai> TabAtkins: I don't think punching layers is good, problematic for implementations<br> <fantasai> TabAtkins: have to be in a reasonable situation like bg color on your element<br> <fantasai> myles: but is it good enough?<br> <fantasai> una: could require the first argument to be a solid color<br> <fantasai> dbaron: what is the computed value if you do this contrast color thing?<br> <fantasai> una: result would be a color<br> <fantasai> dbaron: in terms of CSS computed value, how is contrast-color going to inherit?<br> <fantasai> chris: I think the computed value would be the winning color<br> <fantasai> TabAtkins: It's a good question, need to figure that out<br> <astearns> q?<br> <fantasai> AmeliaBR: Question of how we dealt with currentColor -- it inherts as a keyword, and also wanted to switch the system colors to do that also<br> <fantasai> AmeliaBR: If we do that, then it would be awkward if the contrast selection is set at the body level but the actual element using that color has now the value of that varable or keyword ahs a different value<br> <fantasai> chris: If computed value is as specified ...<br> <fantasai> leaverou: Might not want a different alue on the child<br> <fantasai> dbaron: Part of my concern here is that except for this thing, it seems like the computed value can be computed to a color<br> <leaverou> s/Might not want a different alue on the child/even if it's a CSS variable, it could have a different value on the child/<br> <fantasai> dbaron: but this is the one thing in all this color adjustment stuff thats "layout"-dependent thing<br> <fantasai> TabAtkins: I don't think so... but if one of the options s currentColor or currentbg or whatever, then it's an issue<br> <chris> q?<br> <fantasai> fantasai: Systme colors also vary by element<br> <fantasai> dbaron: when you're doing style computation, you know what hte coptued value of the color property is. So you can know what currentcolor is as a color<br> <fantasai> AmeliaBR: we choose to inherit it as a keyword rather than a color<br> <fantasai> dbaron: Same for system colors. You can do the lookup<br> <fantasai> TabAtkins: Then I don't understand why other color mods are different<br> <fantasai> dbaron: I think all of that can happen in computed value<br> <chris> https://github.com/jonathantneal/postcss-color-mod-function<br> <fantasai> dbaron: The question is, is this definition of "aht is the relevant bg to contrast with", what does it depend on and is it something that can be resolved at computed value time locally?<br> <fantasai> dbaron: Or do you need to do layout to find out?<br> <fantasai> TabAtkins: Just being able to contrast with element's own background woudl be enough<br> <fantasai> AmeliaBR: I think it's better to leave out idea of "current background" rather than having overly-simplistic definition<br> <fantasai> AmeliaBR++<br> <fantasai> una: ...<br> <fantasai> una: You don't need it<br> <fantasai> emilio: You can use -webkit-text-fill-color<br> <AmeliaBR> s/.../we can leave out current background for now/<br> <fantasai> chris: If syntax is you put two colors in here, then new keyword<br> <fantasai> myles: I brought up contrast-color in order to differentiate from other functions<br> <fantasai> myles: picking between proposal A and B, contrast-color is distinct from either<br> <fantasai> myles: Ignoring it for the moment<br> <una> s/need it/need it because you can put currentColor in that slot and specify the background behind currentColor/<br> <fantasai> myles: Both of these proposals are saying here's some syntax, take the color, do some math in a coor space, and then put it back into a color space<br> <fantasai> myles: But do designers think in that terms?<br> <fantasai> myles: Amelia said about blend modes<br> <AmeliaBR> q?<br> <fantasai> myles: Instead of describing as channels independently, maybe match ? maybe match better how designer would think about it<br> <fantasai> AmeliaBR: I don't think they're opposing concepts<br> <fantasai> AmeliaBR: I think Una's proposal had an adjust color and a mix color<br> <fantasai> AmeliaBR: I'm suggesting an adjust color using oneof these syntaxes<br> <fantasai> AmeliaBR: And a blend color<br> <fantasai> AmeliaBR: Adjust color is lighten or brighten or dullen<br> <leaverou> q+<br> <fantasai> AmeliaBR: Mix is for ppl thining more of combinin two colors<br> <fantasai> AmeliaBR: You can interpret lighten / darken as combine with white/black<br> <florian> q?<br> <fantasai> AmeliaBR: but ...<br> <fantasai> leaverou: Wrt proposal A and B<br> <fantasai> leaverou: ? doesn't have mix color or contrast color<br> <fantasai> leaverou: so it's really about picking how to do the adjustments<br> <fantasai> leaverou: lighter / darker / more opaque / more translucent / etc<br> <AmeliaBR> s/.../you can't make saturation brighter or duller that way/<br> <AmeliaBR> s/?/my proposal/<br> <fantasai> TabAtkins: We have strong existence proof that ppl do think about this in terms of color adjusters, because every preprocess has a variant of channel adjusters<br> <fantasai> TabAtkins: might not be ideal, but super common<br> <fantasai> leaverou: Wrt blending modes<br> <fantasai> leaverou: My experience is that designers how blending modes work<br> <astearns> +1 leaverou<br> <fantasai> leaverou: Every time I give a talk about them<br> <astearns> s/designers how/designers don't know how/<br> <fantasai> leaverou: ppl come up to me, I didn't understand how these work, just tried different ones to see the result<br> <fantasai> una: ...<br> <fantasai> una: You can also clikc around in devtools to see what works for you<br> <fantasai> una: A huge use case for color funcitons is to create palettes from a single source<br> <fantasai> una: so you'll still need color adjustment and not just mixing<br> <fantasai> mstange: Two existing ways to mix colors<br> <fantasai> mstange: gradients<br> <fantasai> mstange: and transitions<br> <astearns> ack mstange<br> <fantasai> mstange: Is the ? color function equivalent to what those do?<br> <fantasai> mstange: or is that something we want?<br> <fantasai> TabAtkins: we should offer one<br> <fantasai> TabAtkins:both of those interpolate in premultipled sRGB space<br> <fantasai> TabAtkins: not idea space<br> <fantasai> TabAtkins: but good to provide that so can match<br> <fantasai> una: could remove arugments of whcih manipulations, and then mix those two colors evenly by default in sRGB<br> <fantasai> AmeliaBR: Agree that if we have a default it should match default for gradients and tansitions<br> <leaverou> s/My experience is that designers how blending modes work/My experience is that designers don't really understand how blending modes work, they just try things until they get the desired result/<br> <fantasai> AmeliaBR: I would also like to define gradients and transitions to one day use other color spaces<br> <fantasai> AmeliaBR: e.g. color-interpolation from SVG whch nobody implements :(<br> <fantasai> AmeliaBR: want to say "mix in LCH"<br> <fantasai> chris: Had that in spec 10 yrs ago, had to take out<br> <fantasai> chris: Not that we contro lvia CSS, but antialiasing of forreground shape and bg shape, that also requires interpolation<br> <fantasai> chris: and that's again different<br> <fantasai> chris: but it's all linear interpolation and have to specify the color space<br> <fantasai> leaverou: Drawback to interpolation in LCH?<br> <fantasai> TabAtkins: Doesn't match<br> <fantasai> leaverou: but result is same or better?<br> <fantasai> TabAtkins: proably<br> <fantasai> markus: So if I'm shifting from red to green, do I go around the circle or through to gray<br> <fantasai> chris: L axis<br> <fantasai> chris: black is zeor<br> <fantasai> chris: 100 is reflective white<br> <fantasai> chris: on screen whatever native white is<br> <fantasai> chris: 50% is visually midway between black and white<br> <fantasai> chris: if you move 10% it is equal -looking steps<br> <fantasai> chris: then have A and B axis which are cones from your eyes<br> <fantasai> chris: ... oppostie collor through the L<br> <AmeliaBR> s/zeor/zero/<br> <fantasai> chris: ...<br> <fantasai> chris: LCH is the polar form of that, ou have a hue angle starting from A axis and going round<br> <AmeliaBR> s/oppostie collor/opposite color/<br> <fantasai> chris: you have chroma which is like saturation but better<br> <fantasai> chris: L axis is neutral axis<br> <fantasai> chris: that's perception<br> <fantasai> chris: moving by constant amount<br> <fantasai> AmeliaBR: to ansewr your question, you're converting a color to a vector of 3-4 numbers, and then doing simple interpolation of the numbers<br> <fantasai> chris: If you itnerpolate LAB you'll get a striaght line<br> <fantasai> chris: iF you interpolate in LCH you'll also sweep through hue angle, see the rainbow<br> <fantasai> chris: if you wnat to go through gray then you want LAB<br> <astearns> q?<br> <fantasai> AmeliaBR: Can we make a resolution that we all agree color modificaiton functions are a good idea and have them?<br> <fantasai> q+<br> <fantasai> chris: I would like us to do that, actually<br> <fantasai> chris: ppl think we don't care, but we do<br> <fantasai> TabAtkins: it's just that my previous proposal sucked<br> <florian> fantasai: my suggestion would be: if we have a clear idea of which proposal we want, we should decide now, but otherwise, we can put both in the spec for now<br> <florian> fantasai: then it's not just a giant issue, we can work on it, we can iterate, and people can see what we're working on<br> <florian> chris: I like that idea, but i'd rather do it in css-color-mod-1 rather than css-color-5<br> <florian> fantasai: I think we should finish color-4 quickly, and then color-5 won't seem that far out<br> <fantasai> AmeliaBR: If color mod and LCH come togheter can be in the spec<br> <fantasai> AmeliaBR: we have two proposals right now<br> <fantasai> AmeliaBR: conrast function seem to all like thate xcept for current bg, so maybe resolve on that?<br> <fantasai> leaverou: and maybe mixing?<br> <fantasai> AmeliaBR: So maybe mix with color space option<br> <fantasai> astearns: LCH is not currently in color 4?<br> <fantasai> astearns: So could put this into color 4<br> <AmeliaBR> s/So maybe/And I recognize that blending is nice but confusing, stick with/<br> <fantasai> fantasai: I think we should put into color 5 and get color 4 into CR<br> <fantasai> chris: Implementer interest???<br> <myles_> q+<br> <astearns> ack fantasai<br> <fantasai> TabAtkins: We're done with the *spec*, we can put it into CR. Just can't go to REC because waiting for implementations.<br> <florian> fantasai: we don't want to conflict REC and CR. even if we don't have implementations, if we're done with the spec, it should go to CR<br> <florian> fantasai: and then this new stuff needs design work, so it should go in different level because we'll file issues, make big changes, etc. So new level or new module<br> <chris> s/conflict/conflate<br> <leaverou> q?<br> <leaverou> q+<br> <florian> fantasai: I'd prefer color level 5, because it really is the same scope as colors in general<br> <astearns> ack leaverou<br> <fantasai> leaverou: One issue with putting i neparate module, if we go with proposal B, it modifies the gramar of the <color> functions<br> <fantasai> AmeliaBR: That's a good argument for color level 5<br> <fantasai> astearns: Chris, would you objet to css-color-5?<br> <fantasai> chris: No, and volunteer to edit<br> <fantasai> TabAtkins: I don't want to, but maybe Una?<br> <fantasai> una: sure<br> <argyle> rad!<br> <fantasai> astearns: So put some subset of these proposals into css-color-5 with Chris and future Una as editors<br> <AmeliaBR> s/i neparate/in a separate/<br> <fantasai> RESOLVED: Put all the proposals into css-color-5, ChrisL and future Una as editors<br> <fantasai> myles_: Please please please no underscores<br> <fantasai> chris: Some languages are positional, others need to name them...<br> <fantasai> TabAtkins: We have lucky thing that function name gives single-letter name of channels<br> <fantasai> TabAtkins: can use that<br> <fantasai> leaverou: but what about alpha?<br> <fantasai> TabAtkins: a<br> <fantasai> TabAtkins: but LAB?<br> <fantasai> TabAtkins: other a!<br> <fantasai> ...<br> <heycam> rbga(x, y, z, w) => rgb(calc(x + 20), 100, calc(z - 20))<br> <heycam> to name the arguments you want to use<br> <fantasai> astearns: let's resolve to put color-contrast in the spec<br> <AmeliaBR> s/TabAtkins: but LAB?/leaverou: but LAB? It has a, plus alpha.<br> <fantasai> una: Going to rename color-conrast, color-mod, color-mix<br> <fantasai> RESOLVED: Rename to put 'color' first, adjust-color -> color-mod()<br> <fantasai> RESOLVED: Add color-contrast() without currentbg<br> <leaverou> TabAtkins: why not just .2?<br> <florian> fantasai: we should make sure we align it with the syntax for crossfade<br> <florian> fantasai: ... to the extent possible<br> <fantasai> RESOLVED: Add color-mix(), try to align with cross-fade()<br> <fantasai> astearns: So two remainign option for color adjust<br> <fantasai> astearns: could put both in the draft and add an issue that we only need one of htese<br> <fantasai> astearns: or show why we need both<br> <fantasai> astearns: or decide now on which to pursue<br> <fantasai> astearns: anyone have a strong opinion which way to go?<br> <fantasai> TabAtkins: I'm reasonably leaning towards Una's proposal because I helped work on it<br> <AmeliaBR> And color-mix suggesting the name of mix() for the generic interpolation of numbers, etc.<br> <fantasai> fremy: My perspective is, Lea's proposal is very useful but believe storngly we can do that with custom functions<br> <fantasai> fremy: this is kind of math we cna do with it<br> <fantasai> leaverou: how does that work?<br> <fantasai> AmeliaBR: it's a Houdini proposal<br> <fantasai> astearns: I think that's true of all of these functions<br> <AmeliaBR> s/cna/can/<br> <fantasai> fremy: Arbitrary math it's not different from doing math in JS<br> <fantasai> fremy: but Una's proposal translates to designer vocabulary<br> <fantasai> fremy: I don't think there's value in creating a new function with special parsing etc. for math<br> <fantasai> fremy: I would prfer to do a custom function, re-use in your JS<br> <fantasai> chris: Are you arguing to remove calc()<br> <fantasai> fremy: what???<br> <fantasai> astearns: This is not a useful discussion.<br> <fantasai> leaverou: they are equivalent modifications, just syntax is different<br> <fantasai> fremy: yes, but if I have to choose between them I prefer the one more scoped to what designers use<br> <fantasai> una: my proposal is more simplified than Lea's, her's has more power<br> <fantasai> una: You have to specify each channel even if blank<br> <fantasai> una: but first proposal is simplified version, do by channel, but using keywords<br> <fantasai> fantasai: I suggest putting both in the spec, issue at top, request feedback<br> <fantasai> astearns: Useful to have both proposals in a spec where people can see them<br> <fantasai> fantasai: and also file issues, improve them, and compare the improved versions as well<br> <fantasai> astearns: arguments against?<br> <fantasai> AmeliaBR: It needs to be very cleary set out even if someone is jumping to heading in the document<br> <fantasai> AmeliaBR: so ppl following along can follow the options<br> <fantasai> Can also put the .annoying-warning there<br> <leaverou> basically to use the same example it's color-adjust(blue lightness(120%) chroma(.4)) vs lch(from blue, calc(120% * l) calc(.4 * c) h)<br> <fantasai> astearns: Also, I expect us to chose only one, but it might be that we end up with both<br> <fantasai> astearns: if we have good justification have both<br> <fantasai> una: also might be able to combine them<br> <fantasai> una: because same calculaitons, less explicitly laid out<br> <fantasai> ...<br> <fantasai> TabAtkins: lab vs alpha!<br> <fantasai> leaverou: write out 'alpha'<br> <fantasai> myles_: ?<br> <florian> +1 to putting both in color-5<br> <fantasai> astearns: My proposal is to put both proposals into css-color-5 with keywords instead of underscores<br> <fantasai> astearns: and start opening issues to discuss bits we want to modify<br> <AmeliaBR> s/?/but one is clearly more powerful than the other, it uses calc & you can put anything in there. The other only does multiplications/<br> <fantasai> RESOLVED: Put both color adjustment proposals into css-color-5, with keywords instead of css-color-5<br> <florian> fantasai: are there other things we know we should put in color-5?<br> <fantasai> RESOLVED: Add Lea Verou as editor of css-color-5<br> <fantasai> Una: we're going to make it happen! As long as you make it happen, implementers :)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3187#issuecomment-499206254 using your GitHub account
Received on Wednesday, 5 June 2019 18:42:02 UTC