- 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