- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 30 Aug 2022 19:32:49 -0400
- To: www-style@w3.org
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= CSS Color --------- - Discussed syntax of color-contrast() function. - RESOLVED: Whatever keywords for foreground/background are named, they are are required (Issue #7359) - RESOLVED: Keywords TBD (Issue #7359: color-contrast() should distinguish foreground and background) - RESOLVED: No keyword ahead of algorithm list (Issue #7359) - RESOLVED: Rename to contrast-color() (Issue #7557: Rename color-contrast()?) - RESOLVED: Make candidates optional, use white / black if there's no available options that pass the contrast test (Issue #7345: Make color-contrast() candidates optional) - RESOLVED: We have an unspecified default, the best available to the UA, which gets updated, only allowed when there aren't any candidates. If you include any candidates, algorithm is mandatory (Issue #7361: color-contrast() default algorithm) - RESOLVED: When calculating color contrast between pairs of semi transparent colors, if the background is opaque, UAs should alpha blend the foreground on the background and use that as the foreground color. If the background is also semi-transparent, it would be alpha blended first with an opaque color TBD (Issue #7358: color-contrast() should take transparency into account) - RESOLVED: Amend previous resolution, the canvas color in previous resolution is TBD (rather than opaque version of foreground) (Issue #7358) - RESOLVED: No change (Issue #7556: Behavior of color-contrast() when no level is specified) - RESOLVED: Punt for now, revisit later (Issue #7360: color-contrast() should support ranges of candidate colors, not just discrete color candidates) - RESOLVED: Defer for now (Issue #5153: color-contrast() with automatic continuous lightness adjustment) ===== FULL MEETING MINUTES ====== Agenda: https://github.com/w3c/csswg-drafts/projects/30 Scribe: emilio Scribe's scribe: fantasai CSS Color ========= color-contrast() syntax to distinguish foreground and background ---------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/7359 <fantasai> Suggestion is color-contrast([over|under] <color> <contrast-algo>+, <color>#) emilio: why a + fantasai: Because they're space-separated una: example w/ colors? <fantasai> color-contrast(over white wcag2(AA), blue, red, green) astearns: Which of blue, red, green looks best over white una: I read white as foreground TabAtkins: Proposition first because of gradients una: Here I expect location + color value fantasai: We intended to read not as a param but a proposition bramus: Why not background/foreground rather than over/under? astearns: That also has the same issue fantasai: We could do that <smfr> color-contrast(blue, red, green over white using wcag2(AA)) una: I can see where it's coming from but I don't know... chris: Not sure it has the same ambiguity <dbaron> this is why I like color-contrast(white over [blue red green], wcag2(AA)) <emilio> +1 to dbaron lea: Can be contrast for icons too right? chris: The algorithm is only about text <smfr> I suggest color-contrast(blue, red, green over white using wcag2(AA)) fantasai: We generally put arbitrary long lists at the end <lea> +1 to fantasai una: I'd make contrast algorithm first una: So wcag2, white over blue, green, red TabAtkins: The algorithm could be typed first fantasai: Everything before the first comma can be reordered <una> so you could write: `color-contrast(wcag2(AA) white over, red, blue, green)` chris: Algorithm can specified against the target, what if you don't have a target contrast? <lea> Could we maybe use a keyword before <contrast-algo>+ ? E.g. using <contrast-algo>+? color-contrast(using wcag2(aa) ...) <fantasai> color-contrast(over white wcag2(), red, blue, green) <fantasai> or <fantasai> color-contrast(over white wcag2(max), red, blue, green) <TabAtkins> not `white over`, that would be invalid <TabAtkins> specifically because the order you put it in reverses the meaning <TabAtkins> (`over white` and `white over` read as exactly opposite things) <dbaron> (because they are opposite things!) una: Over before the value is hard to read dbaron: I think the bracketed list was nice but some people don't like that fantasai: I think syntax here should parallel gradients lea: also color-mix() emilio: Given confusion about ordering of stuff, can we choose some fixed order? emilio: If you can reorder this stuff, we are getting confused TabAtkins: Preposition and color have a fixed order TabAtkins: but algorithms can be moved around emilio: Why do we want to specify multiple algorithms? TabAtkins: Example was, if tomorrow someone comes up with the best contrast algorithm that works perfectly TabAtkins: but you also need to satisfy WCAG2 for legal reasons TabAtkins: you will need to specify two algorithms chris: 2 algorithms or multiple? TabAtkins: 1 or more TabAtkins: you have to pass all the thresholds TabAtkins: If they disagree on white or black, we prioritize the first specified algorithm una: Wouldn't that give us the same problem with color list last? fantasai: They're not comma-separated, and you will likely only have one or two una: Could space-separate color list TabAtkins: That would prevent us from adding any parameters to the list, which I don't think we want to do <astearns> I think I'd prefer `white background` and `white foreground` meaning the color is in that slot astearns: I'm not happy with the proposition, I'd rather have a noun phrase astearns: because it's not misinterpretable fantasai: do we want to go for the full word of just fg/bg? * bramus had same concern as astearns una: don't mind that una: I think it's more readable because color is first <lea> not abbreviations please! bramus: background / foreground is clearer to me <bkardell> color-contrast(black foreground wcag(), red, blue, yellow)? <bkardell> is that the suggestion? una: If we're having foreground/background what about if you have a border or so? fantasai: I think you pick your contrast algorithm and pick something fantasai: usually it's not equal amounts of colors fantasai: so that's what you'd use as background lea: Given most contrast algos don't distinguish background/ foreground, could we have a default? lea: so that we don't need to specify? chris: So the first one can be one of them? TabAtkins: What about the algo that does care? TabAtkins: Why not make it grammatically required? Some algos don't care numerically but dbaron: Why not make it grammatically required (just for the algorithms that require it)? lea: Also can we not do bg/fg (abbreviations)? lea: Also can we have a keyword before the algorithm so it's easier to read? TabAtkins: We usually don't do that unless needed for disambiguation TabAtkins: Proposal is a keyword to separate the algos from the rest of the stuff, like put the keyword "using" in front or so fantasai: we don't need it so I don't think we should add it TabAtkins: agreed <bramus> `color-contrast(<color> [background|foreground] using <contrast-algo>+, <color>#)` then? <una> +1 dbaron: What I was suggesting is to require foreground / background only when using an algorithm that needs it, otherwise optional lea: That's what I meant TabAtkins: So it'd be grammatically invalid to not provide it? dbaron: Yes <TabAtkins> color-contrast([ [ <color> [background|foreground] ] && <contrast-algo>+ ], <color>#)` una: Related to the following question, auto would always require it florian: Some algorithms require foreground/background, are there other things? chris: Not so far chris: There's a proposal to add a third color which is the surround florian: e.g. to get a numerical value of wcag you don't need font-size, but AA/AAA does florian: Does that become an input? chris: That's a good question and I think background/foreground is reasonably special florian: I suspect font-size is quite special too? TabAtkins: You can specify the level as well florian: If you know the font-size fantasai: Since the algorithm takes params we could communicate there lea: It'd make the grammar harder to define that as a conditional requirement TabAtkins: We'd define it in prose TabAtkins: A bit annoying lea: If we use a default we don't have that problem TabAtkins: Yeah but that means that people will forget and get confusing answers lea: Maybe mandatory everywhere? TabAtkins: Yeah fantasai: I think that'd be fine <smfr> what is being made mandatory? <emilio> smfr foreground/background <fantasai> smfr, whether the base color is background or foreground <chris> smfr for algorithms that need it, which color is background and which is foreground dbaron: I think right now there's only one algo that needs it and is still in flux TabAtkins: I think intuitively, the fact that a lot of algos don't use it is clear that they are garbage, because changing foreground and background significantly changes the perception of contrast <lea> +1 to TabAtkins <dbaron> ok, makes sense lea: Can we resolve about making bg/fg mandatory? bkardell: Lots of the examples colors are just color names bkardell: Part of the reason we're doing it at runtime is that you might not have known inputs bkardell: I think the complex case is when you don't have a single color background bkardell: e.g. if you look at the screen what the color name should be? TabAtkins: Nobody has put down an algorithm to do that easily bkardell: I think I disagree TabAtkins: In any case it's a much more complex problem <una> real example, say a button: `color-contrast(lightblue background using wcag2(AA), royalblue, navy, darkblue)` <lea> una: `using` was rejected fantasai: I'm happy to make things mandatory, but I'm against adding more boilerplate TabAtkins: That's why I was going for fg/bg lea: over/under aren't that much typing TabAtkins: Less clear florian: front/back? fantasai: That'd work for me una: Issue isn't the naming, was the position astearns: proposed resolution is that the first part of the syntax is color with front/back, applying to that color fantasai: As long as they're reorderable? <una> `color-contrast(lightblue back wcag2(AA), royalblue, navy, darkblue)` <dbaron> do we want to consider fore/back rather than front/back? <una> dbaron -- I think that `fore` might be more confusing <TabAtkins> color-contrast( [ <color> && [front | back]? && <algo>? ], <color># ) <lea> TabAtkins: <algo>+, not ? <TabAtkins> yes, right, typo on my part smfr: I think having the fore/back not applying to the chosen colors smfr: logically I'd think "the color I wanna choose is the front color" astearns: So you'd like the modifier in the color list? florian: We had the same problem with gradient direction, to top left, or from top left? smfr: I kinda prefer under/over but we rejected that so... TabAtkins: Curious about why you think over/under apply to a different thing than front/back smfr: because it's like writing an english sentence, over <foo> I can remember <lea> yeah, I also liked that over/under read more like natural language :/ una: that's why I preferred using too <TabAtkins> color-contrast{start:<color>, position:[front|back], choices: <color>+ } <dbaron> IMO, "white front" is natural language but "front white" is not. <fantasai> 1. over/under <fantasai> 2. front/back <fantasai> 3. something else <florian> 2 lea: What were arguments against over under again? chris: Confusing order una: You could reorder the first three values fantasai: We wouldn't allow to reorder that fantasai: in gradients we do the same <smfr> I like ‘over|under <color>' <emilio> +1 smfr <lea> +1 smfr <una> 2 <lea> 1 <bramus> 2 <TabAtkins> 2 <emilio> 1 <fantasai> 1 <astearns> 2 <chris> 2 <miriam> 1 <smfr> 1 <dbaron> abstain <bkardell> abstain <emeyer> abstain <dholbert> abstain <dbaron> (BTW, with my [] suggestion there's an only-over option where you could write "green over [red white blue]" or "[red white blue] over green".) astearns: No consensus <dbaron> (6 votes for #2, 5 votes for #1, 4 abstain... since some people voted with /me and weren't logged) una: Core issue is do we want to make sure it's required? lea: We concluded it should be required TabAtkins: Proposal to keep keywords undefined TabAtkins poll authors then come back RESOLVED: Keywords undefined RESOLVED: Whatever keywords for foreground/background whatever they are are required RESOLVED: No keyword ahead of algorithm list TabAtkins: Next is comma separation between color list and the rest chris: If I have `over white, green, red, blue` it looks confusing chris: I don't think it makes sense chris: That'd look awful TabAtkins: It'd have the keyword before fantasai: Agree it's a problem dbaron: Same florian: Not sure what's better <TabAtkins> precedence for / is that it's weaker than commas when mixed <TabAtkins> we have several properties using that lea: Right, alternatives are not better astearns: proposal to punt astearns: (until keywords are decided) Rename color-contrast()? ------------------------ github: https://github.com/w3c/csswg-drafts/issues/7557 lea: Right now color-contrast sounds like it returns a contrast, not a color <smfr> +1 to lea smfr can we change the name? color-contrasting / contrasting-color? <dbaron> I like contrasting-color() <fantasai> contrast-color() fantasai: I don't like adding ing lea: I think contrast-color works fine una: I like it <miriam> +1 astearns: objections? <ydaniv> +1 chris: I think we had them and then we harmonized with color-* chris: but agree it's better the other way RESOLVED: Rename to contrast-color() (discussion in #7359) <lea> so it will basically be only contrast-color(over var(--color))? <TabAtkins> yes <una> I love the usefulness of `contrast-color(over var(--color))` color-contrast() default algorithm ---------------------------------- github: https://github.com/w3c/csswg-drafts/issues/7361 fantasai: (1) use UA chosen algo that can change over time (2) wcag2 forever (3) always require name of algo (4) algo keyword mandatory for now, pick a default later (5) do UA chosen algo, but only allow syntax without candidates--so always returns either white or black fantasai: for (5) so you don't have these more subtle color distinctions fantasai: We can use wcag2 by default now and change it, without more subtle changes chris: I disagree with lots, first that white / black are not much change florian: It won't chose between brand color and something else chris: wcag2 default is problematic. We already have a formal objection TabAtkins: To get around that we can leave the algo undefined to UA determination <lea> if we can also provide the algorithm, we've just resolved #7345 florian: It's probably good to not say it's WCAG, which means people wouldn't rely on it for legal reasons astearns: So with option five you it's invalid if you provide candidates? fantasai: Yes astearns: If we go for (5) we also go for (4) when we have candidates? fantasai: Yes lea: Wanna point out since we are about to resolve in the simplified form, if we can also provide an algorithm, can we resolve #7345 first that allows us to avoid candidates? Make color-contrast() candidates optional ----------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/7345 fantasai: Proposed resolution is that candidates are optional and default to white and black una: Sounds good, it simplifies the function. We've talked about future-proofing and verbosity I think this is perfect, and I think "I just want good contrast" will be a large use case <lea> color: lab(contrast-color(over var(--color) l a b / .8); emilio: what happens if you have one candidate? TabAtkins: you just get white/black if you fall off the list <lea> emilio: if that passes, it's returned, otherwise you get white or black RESOLVED: Make candidates optional, use white / black if there's no available options that pass the contrast test color-contrast() default algorithm (continued) ---------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/7361 una: I really like having no algorithm specified, just the value you want contrast against emilio: If you fall off the list, do you implicitly end up with white and black and if white passes contrast testing...? TabAtkins: No, you take the one that's more contrasting chris: They're not tried in order, just either give me white or black TabAtkins: if you want to specify the order, give a list <lea> emilio: this is why it's not unfortunate that we're maximizing: color: color-mix(contrast-color(over var(--color), var(--color) 20%); dbaron: Open to default in the future right? TabAtkins: yes <dbaron> (I was responding to a statement of the proposed resolution that wasn't minuted.) florian: So options are either contrast-color(over ...), or contrast-color(over foo <algo>, a, b, c..) right? astearns: Objections with going with (4) + (5) Proposed: We have an unspecified default, the best available to the UA, which gets updated, only when there aren't any candidates. If you include any candidates, algorithm is mandatory <fantasai> contrast algorithm is optional, and defaults to the best available to the UA (which gets updated over time), if no candidate colors are specified RESOLVED: We have an unspecified default, the best available to the UA, which gets updated, only allowed when there aren't any candidates. If you include any candidates, algorithm is mandatory <br size=20min> color-contrast() should take transparency into account ------------------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/7358 lea: Current draft doesn't mention transparency lea: most contrast arguments ignore it lea: If foreground is semi-transparent some algorithms make it work, otherwise ignore it lea: When you have a range of contrasts there's no answer lea: One option would be using the minimum contrast lea: For wcag there's work to compute min/max contrast lea: if foreground is transparent but background is opaque you can alphablend but in the background case it's not so clear cut... florian: For foreground there's an answer. For background, what authors should be supplying is not the possibly semi-transparent background color of the element, but rather the composited background against which the foreground will be seen. It's not necessarily easy for authors to figure what that is, but that's the only thing that makes sense. The color-mix() function might help. dbaron: First intuition is that having a background that's not opaque should be a syntax error dbaron: wrt contrast ranges, maybe alpha-compositing background with alpha over foreground with no alpha might give you the minimum contrast, but might vary per algorithm fantasai: Was gonna suggest the same, composite semi-transparent background over foreground color would give you the worst case scenario fantasai: If both semi-transparent it gets extra-exciting, maybe composite against black? lea: Not sure how we'd specify this so that semi-transparent is invalid TabAtkins: In prose lea: Compositing on black might give you the max contrast chris: If you have stuff like iframes that are transparent, does that allow you to find the background behind the iframe TabAtkins: Not doing that, there's no way to know what the color will be used on emilio: Making it invalid at syntax time sounds nice, but not possible in the presence of currentColor emilio: Offhand, I don't expect this to be a super common thing to happen emilio: doing what fantasai and dbaron suggested seems a reasonable compromise to me dbaron: What I was suggesting if they are both not opaque was to take the foreground, modify alpha to be 1, then composite the background on top dbaron: then compare foreground composited against that dbaron: That was my intuition for the worst case fantasai: [sanity-checks that] <TabAtkins> composite foreground over background over (fg with alpha set to 1) <lea> no need for color-mix(), relative color syntax can do that: lab( from foreground l a b / 1) dbaron: new_bg = alpha(fg, 1.0); background = composite(bg, new_bg); emilio: The goal is to make both opaque emilio: so you need to composite on top of the new background that's opaque dbaron: This is sort of speculative, we should work it out in an issue astearns: Well this would be the issue dbaron: Underlying question is "does this give you the worst case?" lea: Intuitively it seems like it might fantasai: So generically, we have a canvas that is the foreground with alpha 1, then we draw the background, then the foreground fantasai: if everything is opaque then it all works out easily, otherwise you need to do some compositing <TabAtkins> foreground compared against (bg on top of opaque fg) florian: Sounds like it gives a clear answer, not sure it's a great answer TabAtkins: How can you get a less contrasting color with the foreground than the foreground itself <dbaron> It's probably not the absolute minimum for all algorithms, but it's probably close. emilio: I'm not sure it'll be the least contrasting color emilio: the least contrasting option would be the compositing the background with the foreground maxed out TabAtkins: That's the suggestion emilio: But that's not quite the same emilio: The least contrasting option with the foreground is the foreground itself emilio: okay, yeah emilio: If you apply the background, then, yes, that should give you the worst. Nevermind. dbaron: I'm not sure it's the least contrasting. if you state it like fantasai where you have three layers dbaron: the contrast aren't uniform with blending dbaron: so I think there's variations where this might not work <lea> FWIW this was the research I had done 10+ years ago on min/max WCAG contrast: https://lists.w3.org/Archives/Public/w3c-wai-ig/2012OctDec/0011.html <lea> I can't at a glance tell if the formula for min contrast is what dbaron is proposing florian: Other concern is that if we manage to find the least contrasting situation, we might fall back to black / white unnecessarily, as what's behind the semi-transparent background might not at all be that worse case scenario fantasai: I think dbaron's proposal is the best option, I propose to spec it and let people tell us why we're wrong <lea> +1 fantasai emilio: I think what I was thinking is along the lines of what dbaron thought earlier emilio: the worst contrast is when the blend of the background color and the color below it is exactly the foreground emilio: using the foreground color itself doesn't give you the worst one emilio: Suppose you have a red foreground, opaque red emilio: and you have semitransparent white background emilio: Can you get a way such that compositing semitransparent white will end up red? RESOLVED: When calculating color contrast between pairs of semi transparent colors, if the background is opaque, UAs should alpha blend the foreground on the background and use that as the foreground color. If the background is also semi-transparent, it would be alpha blended first with an opaque version of the foreground TabAtkins: A medium gray foreground, half-transparent black background, clearly the worst contrast is putting it over white TabAtkins: putting over medium gray is not as bad emilio: It's probably good enough florian: Could also just put white or black as the backdrop, depending on color scheme emilio: [missed] emilio: Gecko does have some contrast checks for selection emilio: What we do in the case of semitransparent backgrounds is using the default background <TabAtkins> Notably the worst case here is 50% transparent background as it gets more or less transparent, the answer becomes easier emilio: Basically composite with canvas, can guarantee it's opaque emilio: Simpler answer, maybe more correct TabAtkins: How about we resolve for now that we'll adopt this approach with a color TBD TabAtkins: Could still use examples and thought RESOLVED: Amend previous resolution, the canvas color in previous resolution is TBD (rather than opaque version of foreground) Behavior of color-contrast() when no level is specified ------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/7556 lea: Right now per spec if no level is specified (wcag()), behavior is to get the most contrasting color, vs if you provide a level (wcag(aa)) you get the first that passes lea: I think that's a bit inconsistent, ignores preference order lea: Not sure what use cases it covers lea: and is inconsistent with general use of functional notations where if you omit something it defaults to something lea: So basically magic fantasai: Not magic lea: It's magic in the sense that there's no way to pass an argument to do the same emilio: I think I agree, either choosing a reasonable default or making the level mandatory are both reasonable options astearns: Are the levels fixed? emilio: They depend on the algorithm astearns: Seems slightly better in the sense that if we add a level behavior doesn't change? TabAtkins: Not really, if we're choosing a default. I prefer making it mandatory because the level depends on your use case. People might not understand them but at least it's affirmative action, not "I wrote the shortest thing" chris: You increase contrast so that legibility improves and reading speed improves, up to a point, so there's an argument to be made that there's an optimal contrast fantasai: But optimal isn't gonna be any of the minimums that we have here fantasai: I think the behavior of picking the max is reasonable, and if we want a keyword to represent we can add it fantasai: and there are use cases for having a bunch of colors and picking the best, and defining what an optimum contrast is not feasible fantasai: so I'd rather stick with the max behavior, and if we want a max keyword I won't object chris: I don't think you really responded to my point fantasai: If you have infinite colors to choose from I agree with you, but we're choosing between two or maybe three colors from the author miriam: Does this mean that on this case we won't ever fall back to white / black? fantasai: Yes emilio: If you don't specify any color you pick between white / black right? fantasai: Yes, if there's any explicit colors you choose among them dbaron: I think we're discussing two things dbaron: One is that the syntax is confusing because it switches between modes dbaron: The other is that the other mode is not useful dbaron: One way to fix the former might be to have two different functions fantasai: I'm not sure they're sufficiently different to warrant 2 different functions fantasai: I'm fine adding a max keyword lea: People with dyslexia actually find very high contrasting text harder to read, so more contrast might not be better lea: but as una has mentioned already, authors not always want the highest contrast lea: they have preferences lea: Also I don't think authors will provide only a couple colors, but will choose a span of colors lea: Also it was pointed out that this mode is a bit inconsistent when where you specify a level you can always fall back to white and back lea: like if you have blue and dark blue fantasai: That might be what you want if your color is not for text lea: But I think that default is not reasonable fantasai: If the author doesn't want maximal contrast they should not pass white/black to the list, this default always chooses one of the provided colors, is easy to understand fantasai: You might not want the maximum contrast, but wanting the maximum inside a set is reasonable fantasai: and getting the first that passes the bar might not always be what you want astearns: If we go with what's specced now that's a lot easier to understand than picking a level and find a reference, and see why you're getting a particular color emilio: I think we're in agreement that the mode that fantasai describes is reasonable emilio: There are use cases for that, nobody's disagreeing right? emilio: The question is whether it should be the default emilio: It's a bit weird that you pass an argument and it changes, maybe we pass the algorithm as a keyword rather than a function? But I guess some algos want parameters... <lea> wcag2(max) sounds like it gets you the maximum wcag contrast (21). Perhaps it should be a preamble modifier florian: Agree with fantasai that it's useful behavior. I think either this is the default mode when there's no threshold, or there's no default and you must specify a threshold or invoke the mode with a keyword florian: having something else be the default feels very arbitrary and possibly wrong <fantasai> +1 emilio: Agree lea: One thing I pointed out in irc is that if we make it a max argument looks like it gives you a maximum contrast (21) which you can always get with white and black lea: should it make a different modifier? fantasai: I propose we keep it the default and if we find a good explicit syntax for that we add it RESOLVED: no change representing ranges of colors in color-contrast() ------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/7360 lea: There's a discontinuity between how designers design UI and how the contrast-color() function works lea: They often have a base color and adjust coordinates (usually lightness) to get sufficient contrast lea: Right now it's possible but you'd need to provide a bunch of colors to simulate a range lea: it'd be nice if you could simplify that usage lea: Not sure if it would need special syntax, or even if we want to do this lea: We might want to punt on it and do it only if people actually do this dbaron: When you suggested syntax, before you said gradient my initial reaction was to use the interpolation syntax dbaron: I think you could reuse the interpolation syntax without specifying the end dbaron: it's basically gradient without direction / radial stuff dbaron: Other thought is that this is difficult to explain with multiple contrast functions dbaron: if you specify something that's a range of color we specify the order in which you process them in lea: I think before we dive down into details we should decide if we want to pursue this lea: what that syntax would look like is secondary emilio: I think I'd rather punt on it for now emilio: There are a bunch of things to figure out, e.g. what are the steps you use for lightness? emilio: What's the resolution of all the colors you try? emilio: You may try 1000s of colors to find something emilio: seems a bit unpredictable, perf-wise emilio: I guess you can binary search, maybe? <astearns> evaluating all the colors for multiple algorithms seems expensive emilio: Assuming contrast is always increasing or decreasing emilio: so unless we find people actually doing this, emilio: if you pass 1000 colors, then worst case you evaluate 1000 colors <dbaron> yeah, I think you can't assume that contrast is always increasing/decreasing emilio: For now I'd rather defer this emilio: I'd rather get the bits we know we want right, and then if we want to extend, we can always do it TabAtkins: You can't assume contrast is monotonic if you interpolate hue TabAtkins: so sampling frequency becomes important TabAtkins: so I say we punt for now <lea> I actually agree RESOLVED: Punt for now, revisit later color-contrast() with automatic continuous lightness adjustment --------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/5153 lea: So this is similar to the previous problem we discussed where you have a given color and you want to lighten or darken it enough so that you get decent contrast lea: I think in this case the contrast does tend to be monotonic lea: so you might be able to binary search lea: We could punt as well for now TabAtkins: I don't think this one is problematic but might be worth punting for the moment miriam: I think this is useful, it's something that a preprocessor can do in a bunch of cases, but it's ok if we delay it astearns: People want to ship contrast-color() so the simpler the better for now emilio: Was going to mention, what we use internally for a lot of these use case emilio: it's not lightness, luminance more generally emilio: In order to replicate a default color palette with an arbitrary accent color emilio: we have a function to adjust the function to a given luminance TabAtkins: That's just relative color syntax emilio: I think unless we have any pressing issue, I vote to punt emilio: This seems extremely similar to what we discussed emilio: so maybe punt RESOLVED: Defer for now
Received on Tuesday, 30 August 2022 23:33:20 UTC