[css-color-6] Let's finally settle contrast-color() syntax

[LeaVerou]

@fantasai and I did a fair bit of work on css-color-6 these past couple of days, but until the WG settles on syntax, we cannot have something shippable for contrast-color(), not even for the restricted version we agreed to pull into css-color-5.

For background, the previous, confusing syntax was like:

contrast-color(wheat vs bisque, var(--accent-color), olive, sienna, color(display-p3 0 1 0), maroon to wcag(4.5))

The current syntax is (keywords ridiculous on purpose, as we resolved to have them undefined):

contrast-color(wheat tbd-bg wcag(4.5), bisque, var(--accent-color), olive, sienna, color(display-p3 0 1 0), maroon)

We should a) resolve on three, largely (but not entirely) orthogonal things:

1. Do we want to keep this syntax or change it?
2. What should the keywords be?
3. Do we allow authors to omit the keyword to specify a default (background)?

Problems with current syntax and alternative syntaxes

If <target-contrast> is just an algorithm, the current syntax is a bit hard to parse for humans as there are a lot of sequential keywords:

contrast-color(wheat tbd-bg wcag2, bisque, var(--accent-color), olive, sienna, color(display-p3 0 1 0), maroon)

OTOH how often are colors specified in keywords? Usually authors use hex or functional notations, so maybe this is not a valid concern. Regardless, another syntaxe that @fantasai and I explored was:

contrast-color(wheat tbd-bg wcag2 / bisque var(--accent-color) olive sienna color(display-p3 0 1 0) maroon)

Foreground/background keyword options

One thing to keep in mind for this is that the base color being the background will be far more common.

Foreground	Background	Pros	Cons
foreground	background	Descriptive and unambiguous	Too long
fg	bg	Concise	Abbreviations
text	base	Concise without being abbreviated	foreground is not always text, base is too vague
under	over	Concise, reads naturally	"x over y, z" has entirely opposite meaning to "over x, y, z" so order needs to matter and we cannot use commas because "over x, y, z" looks like a single list

Should we have a default (background)?

In the majority of cases, the base color will be a background, rather than a foreground. Which brings us to the question: should the syntax allow for neither keyword to be specified?

The advantage of having a default is that the syntax becomes concise regardless of which keyword pair we go with, in which case we can just go for a long descriptive keyword for foreground (like foreground) and be done with it. Having sensible defaults is a tenet of good usability.
The problem with having a default is that authors do not learn to think about the distinction, so in practice they may not specify it even when they have a foreground.

[Loirooriol]

I like that contrast-color(wheat tbd-bg wcag2 / bisque var(--accent-color) olive sienna color(display-p3 0 1 0) maroon) has a clear separation between the background color and the possible foreground colors.

But / as a separator inside a function seems a bit weird, why not a comma as usual?

contrast-color(wheat tbd-bg wcag2, bisque var(--accent-color) olive sienna color(display-p3 0 1 0) maroon)

[tabatkins]

contrast-color(wheat tbd-bg wcag2 / bisque var(--accent-color) olive sienna color(display-p3 0 1 0) maroon)

Losing the commas means the syntax becomes completely inextensible in the future; see 'counter-reset' for an example of this being bad. I'd strongly advise against it.

Foreground/background keyword options

I don't recall if we considered top/bottom. They're clear, fairly short, already used, and don't have the ordering concern that over/under do.

Should we have a default (background)?

I think this should be based solely on, when using whatever algo we think is most reasonable (and default, if possible), if the fg/bg decision makes a significant difference in the output. If they're usually pretty close and never terrible when done wrong-way, then sure, make it optional, no need to require something that usually won't matter. But if those aren't both true, then no, we should keep it required.

[LeaVerou]

Losing the commas means the syntax becomes completely inextensible in the future; see 'counter-reset' for an example of this being bad. I'd strongly advise against it.

FWIW there are no algorithms currently that require metadata per color, though it does give me a bit of pause if we don't have the option for the future.

Foreground/background keyword options

I don't recall if we considered top/bottom. They're clear, fairly short, already used, and don't have the ordering concern that over/under do.

I think that's a bit confusing as it implies order in the Y axis, not the Z axis. But feel free to add them to the summary table, the more options we have the better.

Should we have a default (background)?

I think this should be based solely on, when using whatever algo we think is most reasonable (and default, if possible), if the fg/bg decision makes a significant difference in the output. If they're usually pretty close and never terrible when done wrong-way, then sure, make it optional, no need to require something that usually won't matter. But if those aren't both true, then no, we should keep it required.

Right now the only algorithm that even distinguishes them is APCA. @Myndex can tell us (briefly please?) how significant the difference is and whether flipping them produces a terrible result or not.

[svgeesus]

Right now the only algorithm that even distinguishes them is APCA

Distinguishing them is the correct approach.

-41 and 38 are somewhat different, yes :) and even ignoring the light-on dark and dark-on-light polarity indicator, there is certainly a difference. Not terrible, no.

But tossing away the "which one is text" indicator would be a bad design decision.

[LeaVerou]

But tossing away the "which one is text" indicator would be a bad design decision.

We are not talking about tossing it away, just making it optional.

[svgeesus]

just making it optional.

That would be a bad idea. Why?

[LeaVerou]

just making it optional.

That would be a bad idea. Why?

To optimize the common case: background. That way the length of both keywords stops being a concern, as they are only needed in the rare case.

[nt1m]

Personally I'm not fond of including specific algorithm names in the syntax. This should just be abstracted behind background vs. text or something similar, and the UA (or the spec) should pick the ideal algorithm for each case.

[LeaVerou]

Personally I'm not fond of including specific algorithm names in the syntax. This should just be abstracted behind background vs. text or something similar, and the UA (or the spec) should pick the ideal algorithm for each case.

Yeah, that would be ideal, if there was a single optimal algorithm we could use. Sadly, that is not the case. However, that's what we're doing for level 5, but only for returning white and black (no candidates). There is a lot of background here, you can start from #7553 and dig in.

[ByteEater-pl]

fore or front
and back
(without "ground"; these are actual words, so the rule against abbreviations would be obeyed)
maybe?