[mediaqueries-5] Remove (prefers-contrast) as a boolean, and replaced by a new color reduction media query

[FremyCompany]

In #5433, we resolved to remove the forced value from prefers-contrast.

I think the logical conclusion of this, is that there is no more use case for a catch-all (prefers-contrast) that isn't either explicitly low/less or high/more, because I can't come up with a use case where you would want to change something in both low/less and high/more contrast modes and also would NOT WANT apply when forced colors is active, too. If there are still such use cases, they should be pretty rare, and probably warrant an explicit (prefers-contrast: more) or (prefers-contrast: less).

Because of this, I suggest we drop (prefers-contrast) as a boolean flag, while keeping both (prefers-contrast: more) and (prefers-contrast: less); instead of the removed boolean flag, we add a new feature query that indicates that a color complexity reduction might be a good thing. This media query would apply as a superset of a couple of other preferences, some of which are not possible in all operating systems and authors might forget if they have to mention them all explicitly, but have similar implications for website authors, such as:

• high contrast
• low contrast
• forced colors
• reduced transparency
• ...

Proposal: (reduced-colors) boolean media query.

The proposal would be something along the lines of (reduced-colors) (name to be appropriately bike shedded).

The media query would be a syntactic sugar for:
(prefers-contrast: more) or (prefers-contrast: less) or (forced-colors: active) or (reduced-transparency)

Additional questions:

Optionally we could replace (forced-colors: active) by it, by allowing two sub-values, like (reduced-colors: forced) vs (reduced-colors: optional) where optional would match all cases that are not forced-colors.

Does that seem reasonable?

cc @tabatkins @frivoal @cookiecrook

[cookiecrook]

I misunderstood the proposal in the CSS call. I thought @tabatkins proposed removing the prefers-contrast feature entirely. I don't have a strong objection to removing the boolean match, since the explicit value matches will remain for the feature. That said, there may be some value to keeping it. See next comment.

[cookiecrook]

If am I understanding the reduced-colors proposal correctly, we may come to the same disagreement about whether there is a correlation between "non more/less contrast but forced colors" and a desire for reduced visual complexity.

For example, I would have suggested something closer to prefers-reduced-complexity matching (prefers-contrast) or (prefers-reduced-transparency) but NOT (forced-colors), because the force color scenarios that would need reduced complexity would already match either more or less contrast...

[FremyCompany]

All forced colors scenarios do require reduced color complexity, and I would be happy to try to convince you of that :)

First, a technical reason:

Because you only have a handful of colors at your disposal, all types of gradients and box shadows are out, irrespective of the colors that the user chose for the theme.

Secondly, a practical use case:

To give you an idea of what a fully-fleshed forced-colors mode that is not high contrast can result into, here is for instance what Outlook looks like using a "Reduced complexity (light blue)" theme, whose purpose is to limit color usage on the screen, and have all "interactive things" be blue, so that it is easy to see at a glance what is clickable on an user interface:

As you can see, while this theme I presented does not match a "high contrast" criteria because of the dark on light gray, achieving this end result still required a reduced color complexity, for things to work properly.

Just in case this needs some context, this is what a page looks like in this forced-colors mode versus not:

As your can see, irrespective of the choice of colors, the use of gradients and visual complexity has been reduced, to achieve the desired effect.

[FremyCompany]

To summarize, forced-colors is not a "theme" feature, it is an accessibility feature, aimed at making user interfaces easier to use by reducing their reading complexity, through the enforcement of a reduced color palette with semantic meaning. For most people this will pair favorably with a high-contrast theme, but for some it might simply mean a sharply reduced color palette, or even a lower contrast, due to particular eye strain sensitivity.

[tabatkins]

we may come to the same disagreement about whether there is a correlation between "non more/less contrast but forced colors" and a desire for reduced visual complexity.

@fantasai made the argument very well during the meeting that these two concepts correlate by definition: whether you prefer high-contrast, low-contrast, or have a forced color scheme, you are reducing the available space of colors for the page to use. Low-contrast wants the page to more closely-clustered colors, avoiding extremes from using colors far apart in color space; high-contrast wants the opposite, using more extreme colors and avoiding closely-clumped ones; forced-colors gives you about a dozen colors total that you are allowed to use.

In all these cases, because your available set of colors is reduced, you usually want to reduce visual complexity.

• In high-contrast, subtle gradients and shadows are the precise opposite of what the user is asking for; the page should use simpler color blocks and borders to indicate visual hierarchy more obviously instead.
• Low-contrast is typically also associated with a desire for simpler pages, from what I understand of the a11y needs underlying it; it's typically a sensory-processing issue, and again, simpler, plainer visual hierarchy can usually serve their needs better. Even ignoring that, just the fact that you have a narrower band of colors to work with means you can't rely on having as many distinguishable color/lightness levels, and must instead design your page to indicate hierarchy and importance in ways that don't rely as much on color.
• And finally, in forced-colors you simply don't have many colors to play with, and you don't know what they are anyway, so you can't usefully counterpoint them; again, a simpler visual hierarchy is the obvious way to work around the limitations you're saddled with.

Several of us have repeatedly made this argument, and even provided rendering examples showing off the issues we're talking about. It's felt as if your responses have mostly been "I disagree", which has proven frustrating; there's nothing we can discuss there.

because the force color scenarios that would need reduced complexity would already match either more or less contrast...

I don't understand what forced-colors scenario could possibly not want reduced visual complexity. Forced colors needs reduced visual complexity because the colors are forced and from a small palette - the actual identity of the colors doesn't factor into this at all, as far as we can tell. Can you give an example of a forced-colors palette that you think would not benefit from reduced visual complexity (or rather, that wouldn't be harmed by leaving a reasonably-high visual complexity page alone while applying the forced colors), but would if we tweaked the colors to be higher or lower contrast?

[tabatkins]

@FremyCompany

Because of this, I suggest we drop (prefers-contrast) as a boolean flag, while keeping both (prefers-contrast: more) and (prefers-contrast: less)

This isn't possible without doing some bizarre special-casing. Every media query matches in boolean form, based solely on whether at least one non-nil value matches. Without a very good reason to break from this simple generic rule, I'm not okay with adding odd special cases.

[frivoal]

@FremyCompany for the reason given by @tabatkins in the previous comment, I don't think removing the booleanness of the feature is likely to be what we want to do here.

That said:

• The "reduced complexity" use case is now discussed under both (prefers-contrast) (used in boolean form) and forced-colors. Maybe some massaging of the examples could make this better? Suggestions on this front appreciated.

• Adding a new reduced-colors (or reduced-complexity) query might be the path forward, but I'd like to be careful about this: there might be quite a few factorings of existing queries that could be useful queries on their own, and I don't think we want to add many of those, as it eventually gets complicated for authors to know what's what. If we need lots of these, that feels like a sign we didn't quite land on the right design.

[cookiecrook]

I have no problems with a media feature as specific as “reduced color complexity”… If that’s all we’re talking about, I think it’s clear, and I agree with the assessment that forced colors necessitates a reduced amount of color complexity.

The prior disagreement may have been another vocabulary ambiguity. In the accessibility space “simplification” or “reduced complexity” often refers to both visual and functional interface changes, sometimes in the context of developmental disability. Even if we limit the scope to reducing visual complexity (slightly broader term than color complexity), we get into needs that include distractability, as with autism or ADD. The use cases are not limited to vision disabilities.

I remain unconvinced that forced colors is a 1:1 correlation with my understanding of the broader terms “reduced complexity” or “reduced visual complexity.” However, I agree with @FremyCompany et al that it’s a 1:1 correlation with “reduced color complexity.”

[frivoal]

However, I agree with @FremyCompany et al that it’s a 1:1 correlation with “reduced color complexity.”

@cookiecrook Ok, if we agree on that, could you explain a bit what kind of styling you expect authors to write under the
@media (prefers-contrast) { … } other than "reduced color complexity"? (specifically talking about prefers-contrast without an explicit value).

[dlibby-]

One other option could be to have forced colors mode always map to a more or less value for prefers-contrast. Currently @alisonmaher's experimental implementation has > 7:1 mapping to more and < 2.5:1 mapping to less. Per #5224, the WG has thus far chosen not to be prescriptive on what the thresholds are - having a single threshold would allow for the desired usage of (prefers-contrast) as a boolean.

So this perhaps comes down to a question of what styles an author might apply via prefers-contrast (other than 'reduce visual/color complexity') that would have an effect in forced colors mode. If it is a limited set that wouldn't be harmful for users in this 'middle' band of forced colors, then maybe this is a path forwards. From my understanding current guidance is for authors or design systems to use prefers-contrast: less and prefers-contrast: more as a signal to how color palettes are selected which would be overridden when in forced colors mode.

[FremyCompany]

@dlibby- This sounds like a good proposal overall. I guess Forced Colors can map to more contrast by default (if only for the effect of the reduced palette and back plate) until the colors get really close,where the behavior switches to less contrast; therefore setting the boundary so that one of either is always active. I like that proposal I must say.

[dlibby-]

@tabatkins @cookiecrook @fantasai - any thoughts on having prefers-contrast always evaluate as more or less in forced colors mode?

[frivoal]

Having @media (prefers-contrast) (without explicit value) match when you're in forced color mode despite not picking a particularly low nor high contrast is precisely what we were pushing for in #5433, and got overruled about.

If we're having second thoughts about that—because we do agree after all that forced colors does imply reduced color complexity, and that it is appropriate for all cases of forced colors to match @media (prefers-contrast)—I'd rather go back to the earlier design (which is to have one more value of prefers-contrast that matches forced colors that are neither particularly low nor high contrast), rather than pretend mid-contrast things are high contrast. For @media (prefers-contrast) without an explicit value, it would make no difference, but it would avoid having to misleadingly claim a “more contrast” preference that isn't real.

[alisonmaher]

For me, this issue comes down to whether or not the range between more and less is considered a valid contrast preference. Depending on the answer to this, we can narrow down potential options for a path forward.

If we agree that the range in between more and less is NOT a valid contrast preference, then we should not add back forced. This leaves us with the following options:

1. Leave everything as-is (i.e. don’t add any new media queries or new keywords to prefers-contrast).
2. Look into adding a new media query to encapsulate the various intersections of existing media queries (forced-colors, prefers-contrast, etc.) similar to what is being suggested here by @FremyCompany .

If we agree, however, that the range in between more and less represents a valid contrast preference, we have the following options:

1. Add a third value (name TBD) that strictly represents the contrast range between more and less.
2. Adjust the cut-off between more and less, similar to what @dlibby- mentioned in [mediaqueries-5] Remove (prefers-contrast) as a boolean, and replaced by a new color reduction media query #6036 (comment), to ensure that the two values cover all possible ranges of contrast ratios.
3. Add back forced to capture users who lie in the middle range in forced colors mode.

If we were to add prefers-contrast: forced, I think that we would also need to add prefers-color-scheme: forced for consistency, since both are affected by forced colors mode. This would add even more confusion for authors. For this reason and for the various reasons outlined in #5433, my preference in this case would be for option 1 or 2.

And as a note, we'd like to ship prefers-contrast to better serve users with a contrast preference on non-Windows platforms, but we'd like to get clarity on this issue before proceeding given that there is still a divide on the best path forward.

[dlibby-]

Reading and thinking through this again, I realize that my main objection in #5433 was specifically about the forced value - it seems confusing to authors, is redundant with forced-colors: active, and it is unclear what action they should take. However, to the extent that forced colors maps to a contrast preference on the extremes, it seems to logically follow that it should also map to a contrast preference for a forced color scheme that is not particularly high nor low contrast.

Proposal: add a middle value to prefers-contrast (following @alisonmaher's suggestion above), which would match when the less and more thresholds are not exceeded in forced colors. This also allows for the expression of a user saying they prefer neither high nor low contrast (assuming some eventual UI affordance would expose this), which is different than having no preference.

@cookiecrook would you have any objections to adding a middle value?

@tabatkins @frivoal - any further thoughts on this?

[alisonmaher]

Agenda+ to discuss the most recent proposals.

And I will be out the second half of next week (5/26), so proposing this for the agenda for the week of 6/2. (CC: @cookiecrook to see if that timing would work well for you, too.)

[cookiecrook]

@dlibby- wrote:

@cookiecrook would you have any objections to adding a middle value?

If I'm understanding correctly this would match when "forced" colors is either:

• inactive (e.g. Windows default)
• unavailable (e.g. Mac)
• active near a default contrast threshold matching neither more nor less.

If so, I have no objections other than the suggestion that this be called no-preference to match similar media features. There is no discernible preference related to contrast so the other prefers-color-scheme and forced-colors media features would give the author sufficient opportunity to respond.

However, if the intention of the middle value is limited to matching forced colors that are neither more nor less, then it seems like this is a renaming of the forced value that was already discussed in #5433.

I will attend the discussion in case I am missing something.

@alisonmaher wrote:

…agenda for the week of 6/2. (CC: @cookiecrook to see if that timing would work well for you, too.)

Yes, today works. Sorry for the late reply.

[alisonmaher]

@cookiecrook There is already a no-preference value for prefers-contrast. The intention of middle would be for users who have a contrast preference that is neither more or less. (It would not match if forced colors mode or any other contrast preference were not enabled).

Currently, it would only be possible to match middle in Windows High Contrast Mode, but adding a middle value would allow extensibility for any hypothetical features that may allow a contrast preference that falls in the middle range in the future.

And adding middle would be different than adding back forced since forced matched in forced colors mode, no matter what the contrast ratio was, whereas middle would only match for forced color schemes with ratios between more and less.

[css-meeting-bot]

The CSS Working Group just discussed [mediaqueries-5] Remove (prefers-contrast) as a boolean, and replaced by a new color reduction media query, and agreed to the following:

• RESOLVED: Add 'custom' property for defined color schemes that are not high or low

The full IRC log of that discussion

<dael> Topic: [mediaqueries-5] Remove (prefers-contrast) as a boolean, and replaced by a new color reduction media query
<dael> github: https://github.com//issues/6036
<dael> astearns: There are new proposals at the end of the issue
<dael> alisonmaher: Previously resolved to remove prefers-colors:forced. This issue was a follow up to prop a new MQ to capture intersections under redecuded complexity. Various proposals including adding back forced
<dael> alisonmaher: Summerizing various options
<dael> alisonmaher: If middle range is not a valid contrast preference one option is a new MQ to capture intersections
<dael> alisonmaher: Could leave spec as is and add examples to handle
<dael> alisonmaher: If middle range is valid, other options
<astearns> +1 to adding examples of mid-range things, regardless of outcome today
<dael> alisonmaher: If add back prefers-contrast:forced it captures the users in the middle range, but author confusion
<florian> q+
<dael> alisonmaher: Another is adjust the cut off between more and less to get middle range. Might also add confustion
<dael> alisonmaher: Another option is add a third value of middle to capture the preferences. Allows express neither high nor low, but not no preference
<TabAtkins> q+
<dael> alisonmaher: Personally leaning toward a new value, but curious rest of the group thoughts
<astearns> ack florian
<dael> florian: Thanks for bringing this. Middle value, probably name is a big part of usability. Naming aside, is this supposed to be same semantics as forced?
<dael> alisonmaher: Different. Forced value matched no matter the contrast preference. Middle would only match for users in the middle range. Only in forced color mode for now, but could make sense for future values as well
<astearns> ack TabAtkins
<dael> TabAtkins: This is reasonable to me. Fills in the case. Forced but not high nor low. That's the spot we wanted addressed. Use this as a bool to indicate general contrast preference. This is fine
<astearns> ack fantasai
<Zakim> fantasai, you wanted to distinguish middling luminosity contrast preference vs specific hue contrast preference that happens to have middling luminosity preference
<jcraig> q+
<dael> fantasai: My concern a little bit, don't know all usage, but this would be interpreted as I want grey on grey text, but not too grey. Not quite black on white, but more between and author would be encoraged to include that.
<dael> fantasai: Reason we had that is for causes when someone wanted a contrast in hue that was not low or high for luminosity.
<dael> fantasai: If you were going to have fusha on blue it's got a strong hue contrast, but not strong luminosity. THat's presumably middle but isn't want people would picture. I think adding a middle value would add confusion
<Rossen_> q?
<florian> q+
<dael> fantasai: I think anyone pulling out prefers-contrast:middle would be confusing
<dael> alisonmaher: Are you saying naming is confusing or it wouldn't make sense to query a middle value?
<dael> fantasai: Kinda both. How is author supposed to respond to prefers-contrast:middle?
<dael> alisonmaher: Not sure use cases. Making sure if a user i nthat ranger we would capture in prefers contrast bool. Not sure us cases to target middle by itself
<dael> fantasai: We're trying to capture contrasts not high nor low but specific. I think middle is not a good representation of that
<dlibby> q+
<dael> astearns: But there is A preference, just not high or low. Middle expresses the not high or low but may not be expressing the choosen colors
<jcraig> q+ to request that the prefers-contrast MF remain about contrast, and the forced-colors MF remain about forced colors
<jcraig> ack me
<Zakim> jcraig, you wanted to request that the prefers-contrast MF remain about contrast, and the forced-colors MF remain about forced colors
<astearns> ack jcraig
<dael> jcraig: I've caught up on the thread and thanks to alisonmaher about correcting my misunderstanding earlier. As far as I understand only current impl where this matches is impl with forced color that are not high or low contrast
<dael> jcraig: I believe were we landed on #5433 is this middle range may have people matching but doesn't rep anything suffiently about contrast so keeping out of contrast was preferably. BUt forced colors would remain about forced colors
<astearns> other discussion: https://github.com//issues/5433#issuecomment-785251576
<dael> jcraig: This group is matchable if you have not prefers-contrast: more and not less.
<dael> jcraig: I think goal of group was to get to something like prefers reduced color complexity. If we're trying to do that we need to name it something obvious to the author. I don't think middle is for a prefered reduction in complexity. Feel it's muddling
<dael> jcraig: Is the goal that the group wants to get rid of cforced-colors media preference?
<dael> alisonmaher: Main issue comes down to that do we agree middle range is a contrast preference. Different resolutions depending on the answer
<TabAtkins> q+
<dael> astearns: Are you looking to removed forced colors MQ?
<dael> alisonmaher: No. But seemed like matching the middle range in the bool is of interest.
<astearns> ack florian
<TabAtkins> q-
<TabAtkins> My q+ was to suggest "complex", yeah
<fantasai> lol, I'd have suggested "simple"
<Rossen_> Have we considered naming it "custom"
<fantasai> The preference isn't complex. It's for simple color contrast.
<dael> florian: I think I agree with fantasai that middle is the wrong name if we have it. Unusual or unspecific that indicates that there is a preference is better. That people would query that specificially, I suspect for bool is more likely but either way you could query.
<TabAtkins> We name it "--"
<fantasai> Just different from either high or low
<dael> florian: It's possible to query the middle value which is why I like both old and new
<fantasai> Rossen_, that could work...
<dael> florian: As to why reopen I thought I had lost the battle and gave up but immediately after it was closed there were question son how to deal with this and fremy posted good examples.
<dbaron[m]> I think it would help with the naming to understand who the users are who have this type of preference, and why they have it (and perhaps how essential it is to their ability to use the web).
<TabAtkins> The only purpose of this third value is to handle pages with reduced color palettes that can't otherwise be categorized as high or low contrast.
<dael> florian: Crux of the issue is it's 1 to 1 with prefers reduced complexity. Important thing is how it will be used. Typical thing in context of the bool query for prefers-contrast without a spec of high or low is to reduce color complexity of the page. Seems odd to have a query for that but fails to capture a set of the users
<dael> florian: When query with intent of reduce complexity this almost always gets you there, so why not make sure it gets all the way
<dael> florian: Given it was reraised and you agreed it was 1 to 1 with reduced color I thought why not
<dael> jcraig: Main goal is to get back to previous value of bool match?
<dael> florian: TO me, yes. If you use first contrast as a bool it would be useful if it matched odd contrasts. Not sure what you would use that to match and not want these people
<dlibby> q-
<dael> jcraig: My recollection is I do agree there could be a corrilation between a desire for reduced complexity and forced colors. Thought we settled that should be something as a clearly named MQ. COuld be if you have high or low contrast it would also match prefers-reduced-complexity
<florian> q+
<dael> jcraig: It could match @media for prefers contrast and prefers reduced complexity. Todya should be able to do it with @media prefers-contrast or forced-colors
<astearns> ack fantasai
<Zakim> fantasai, you wanted to express that the goal here is to make sure that everyone who has a contrast preference is captured under (prefers-contrast)
<jcraig> q+ to answer Alison's question that I don't think the `middle` value represents a contrast-specific preference... It does represent a color preference but not contrast.
<astearns> q+
<dael> fantasai: To go back to what is goal of issue- make sure everyone with any color contrast preference get captured under prefers-contrast:true. Low and high preference are captured under low and high keywords. WE want anybody with a contrast preference that's neighter low nor high luminosity are also captures under yes so they are captured
<astearns> ack florian
<dael> fantasai: That's separate...you will impl that as reducing color complexity but that's a question about what does pferfers contrast me
<fantasai> s/impl/often implement/
<fantasai> s/pferfers contrast me/prefers-contrast mean/
<fantasai> s/that's a/this is the/
<dael> florian: It's a question of consituancy priority. Put users first. Author thinking about the problem with all angles could get there however I think it is typical for authors to not think of every case and hope it's useful. I don't think anybody has example of piece of style you would write under bool prefers-contrast that wouldn't be useful to people with unusual scheme.
<dael> florian: Small group, but it is useful. If authors are writing and we could make it apply as useful I think we should. I don't think we should add intent-based queries with feature-based queries.
<jcraig> ack me
<Zakim> jcraig, you wanted to answer Alison's question that I don't think the `middle` value represents a contrast-specific preference... It does represent a color preference but not
<Zakim> ... contrast.
<dael> florian: If there are cases of adding the bool that shouldn't catch these people then the argument falls apart. But the argument that you could target isn't a good reason to exclude these people
<dael> jcraig: Answering alisonmaher from earlier I think she asked earlier do we agree middle is a contrast preference. My opinion is no. fantasai earlier mentioned prefers-contrast more would have a luminosity contrast value and less lower. Middle is luminosity value that doesn't rep contrast in either direction
<florian> q?
<florian> q+
<dael> jcraig: May also be color preference with hues, but that's circumsantial. May or may not be contrast preference in hue, but no preference in luminosity. So I don't think this represents a preference. To help users have to help authors understand what they're trying to do for the users
<Morgan> +1 to jcraig's opinion
<dael> astearns: I wanted to ask...I think we have a problem coming up with a name for the value b/c don't have a good idea of what contrast preference is expressed by having forced colors
<dael> astearns: Agree it would be nice to include people that have choosen forced colors in a prefers-contrast MQ b/c they have expressed preference in colors with some contrast. Can we define it to return true if forced colors is on and not add value?
<astearns> ack astearns
<dael> TabAtkins: Violation of current data model. Not impossible, but seems weird. Only reason trying to do something special is we can't think of a name I'd like to have a name. BUt this is not impossible. This MQ does a slightly different thing with bool than everything else
<astearns> ack florian
<dael> florian: Kind of disagree with jcraig that we should name different to cover everyone. Query specifically for high or low contrast makes sense. If we have those indiviaully and the bool people will sometimes use high or low or sometimes the color and that seems problematic.
<dlibby> q+
<astearns> ack dlibby
<dael> florian: I think bias to easily discoverable doing the right thing is how we get the platofrm to be usable
<dael> dlibby: Back to color preference with hues as sep from contrast. Wanted to check thoughts on forced-color affect prefers-contrast. That statement feels at odds with agreement. To extend forced-color effects prefers-contrast in most cases preference is to have it apply for all cases in the bool context
<TabAtkins> I'm happy with "custom"
<fantasai> +1, wfm
<florian> I'm happy with custom.
<dlibby> custom sgtm too
<dael> Rossen_: I put this in IRC; can we align with calling it custom and stray away from middle or not? Values can be higher or highest and what it comes down to is we're trying to say we know how to capture high and low and inbetween is a custom value that we want to allow authors to take advantage of. As far as naming goes custom makes sense to me
<dael> florian: wfm
<jcraig> q+ to custom is okay... I'm not convinced it's necessary, but I don't feel strongly enough to object
<dael> astearns: Lots of +1 on IRC
<jcraig> ack me
<Zakim> jcraig, you wanted to custom is okay... I'm not convinced it's necessary, but I don't feel strongly enough to object
<dael> jcraig: I'm not convinced it's nec, but not strong enough to object. Custom is a better name than middle. If that satisfies desire to keep bool and embed reduced complexity inferance I think it's probably okay. I can live
<dael> astearns: For my clarification, this 'custom' value would return true if forced colors were active?
<dael> jcraig: And the resulting contrast does name match more or less. More or less defined with luminosity contrast
<dael> astearns: Add a 'custom' value that matches if forced-colors is active but it's not high or low
<dlibby> s/high or low/more or less/
<dael> jcraig: I wouldn't leave it to be forced-colors. Has to do with defined color scheme. Custom color scheme that doesn't match more or less.
<dael> astearns: Yeah, any sort of defined color scheme that's not high or low
<dael> astearns: Obj?
<dael> RESOLVED: Add 'custom' property for defined color schemes that are not high or low

[frivoal]

The pair of screenshots given by @FremyCompany in #6036 (comment) is great for illustrating the situation:

I'd like to include it as an example in the spec to illustrate a realistic usecase and the corresponding styling choices. However, these images are of a real web site, and include someone's brand (Microsoft Edge). Is that considered inappropriate content for a spec and I should created an unbranded equivalent, or is it fine as is?

cc: @astearns @atanassov

[hober]

@cookiecrook, does this custom value work for you?

[cookiecrook]

If I understand correctly, custom is a renaming of the middle value from the June 2 meeting? If so, that seems fine.

Update: I reread the minutes from that meeting and my recollection was confirmed.

The custom value would NOT match anything on the Apple platforms atm, because it is mainly a consolation for the rare Windows forced color configuration that matches neither more nor less contrast.

My arguments against the new value were that 1) it was ambiguous what authors should do with this match, and 2) it was only circumstantially associated with contrast. However, I didn’t feel strongly enough to file an objection, so the CSS WG consensus was to accept the custom value. Mostly harmless AFAICT, so no serious concern.

Thanks for double-checking @hober.