Open FremyCompany opened 3 years ago
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.
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...
All forced colors scenarios do require reduced color complexity, and I would be happy to try to convince you of that :)
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.
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:
![image](https://user-images.githubusercontent.com/364405/109184207-0aca7080-778f-11eb-9fb0-cbac2f9f1231.png) | ![image](https://user-images.githubusercontent.com/364405/109183660-7829d180-778e-11eb-9113-c1c875c0c1ab.png) |
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.
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.
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.
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?
@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.
@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.
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.”
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).
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 https://github.com/w3c/csswg-drafts/issues/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.
@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.
@tabatkins @cookiecrook @fantasai - any thoughts on having prefers-contrast
always evaluate as more
or less
in forced colors mode?
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 https://github.com/w3c/csswg-drafts/issues/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.
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.
more
and less
is NOT a valid contrast preference, then we should not add back forced
. This leaves us with the following options:prefers-contrast
).more
and less
represents a valid contrast preference, we have the following options:more
and less
.more
and less
, similar to what @dlibby- mentioned in https://github.com/w3c/csswg-drafts/issues/6036#issuecomment-799861439, to ensure that the two values cover all possible ranges of contrast ratios.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.
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?
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.)
@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:
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.
@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
.
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 pair of screenshots given by @FremyCompany in https://github.com/w3c/csswg-drafts/issues/6036#issuecomment-786036068 is great for illustrating the situation:
![image](https://user-images.githubusercontent.com/364405/109184207-0aca7080-778f-11eb-9fb0-cbac2f9f1231.png) | ![image](https://user-images.githubusercontent.com/364405/109183660-7829d180-778e-11eb-9113-c1c875c0c1ab.png) |
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
@cookiecrook, does this custom
value work for you?
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.
In https://github.com/w3c/csswg-drafts/issues/5433, we resolved to remove the
forced
value fromprefers-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: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 notforced-colors
.Does that seem reasonable?
cc @tabatkins @frivoal @cookiecrook