Closed cookiecrook closed 3 years ago
Even though I'm a WG member, I'm not able to add the requested labels. Is that intentionally limited to full editors?
Nope, it's just a manual step for us to add people to the right team. You should be good now.
Whether or not its the right conclusion is a separate question, but the current idea is:
They are indeed the exact same thing. We wish we had though of defining it as prefers-contrast: forced
first, but we didn't, so MS shipped force-color: active
already. We thought we still liked prefers-contrast: forced
better, so we defined that, but since forced-colors: active
shipped, we're keeping it as well for compat reasons. The fact that one is the desired syntax, and the other is the legacy alias isn't currently clear in the spec, but an editorial cleanup should make that more obvious.
So, with that in mind, I think we can take 3 stances:
prefers-contrast: forced
is the better design, but the benefit isn't strong enough to justify a "good syntax" and "legacy syntax", so we should revert the decision taken in https://github.com/w3c/csswg-drafts/issues/3856 to add forced
to prefers contrast
.prefers-contrast: forced
is the better design. Keeping forced colors separate from contrast preferences is desirable, regardless of compat. On that basis, we should revert the decision taken in https://github.com/w3c/csswg-drafts/issues/3856 to add forced
to prefers contrast
.My stance is (1), and as the spec's Editor, I'll do the editorial clean-up to at least make it clear what the current situation is.
I believe your stance is closer to (3). I'd suggest holding off just a bit to see if the clean-up I'm about to do makes things better in your opinion. If it doesn't, it's probably worth re-reading https://github.com/w3c/csswg-drafts/issues/3856 (I'd say from the top up to and including the teleconf minutes of June 11, after that it goes into a number of tangeants, most of which are answered by https://github.com/w3c/csswg-drafts/issues/2943 or by the editorial clean-up I'm about to make), and responding to the points that were made in favor of the resolution that was taken then.
My stance is partially 2 (added 2b below) and fully 3.
2b. Regardless of which syntax is better, there is only one platform that supports this feature and the current syntax is sufficient to cover that platform. Therefore, the benefit isn't strong enough to justify a syntax duplication. If future platform features require additional syntax changes, it would be better to wait until we know what those are.
- I disagree that prefers-contrast: forced is the better design. Keeping forced colors separate from contrast preferences is desirable, regardless of compat. On that basis, we should revert the decision taken in #3856 to add forced to prefers contrast.
Yes to this, too.
Some additional context from Mozilla: we implementforced-colors
and prefers-contrast
too, though they're behind prefs :)
The "forced" parts of our implementations respond to both Windows HCM and Firefox HCM (about:preferences > colors, the dialog allows users to pick customized colors for text, background, visited/unvisited links). We've been doing some work with folks at Google to make sure G-suite sites render appropriately in Firefox when HCM (windows, ours) is enabled. Google is using these preferences to make adjustments (mostly prefers-contrast: forced, if I remember correctly), but our users won't benefit from them until we can unpref. I don't know that I have enough context to take a stance one way or another, but just wanted to give some more usage context :)
@MReschenberg wrote:
The "forced" parts of our implementations respond to both Windows HCM and Firefox HCM (about:preferences > colors, the dialog allows users to pick customized colors for text, background, visited/unvisited links).
To clarify, are you saying the Firefox HCM mode on non-Windows platforms (Mac, Linux) will also match the media features? Good to know. Thanks.
our users won't benefit from them until we can unpref.
By "unpref" do you mean change Firefox to match the Windows system setting? I thought that was already implemented based on your comment that "The 'forced' parts of our implementations respond to both Windows HCM…"
To clarify, are you saying the Firefox HCM mode on non-Windows platforms (Mac, Linux) will also match the media features? Good to know. Thanks.
Yep, exactly -- prefers-contrast: forced will trigger for users running Windows HCM as well as for users on any platform running Firefox HCM.
our users won't benefit from them until we can unpref.
By "unpref" do you mean change Firefox to match the Windows system setting? I thought that was already implemented based on your comment that "The 'forced' parts of our implementations respond to both Windows HCM…"
Ah sorry, bad wording. Right now, Firefox parses prefers-contrast when it finds it in CSS. If it finds the query in a UA style sheet, it'll apply the inner CSS (provided the FF user has some qualifying HCM enabled^). If it finds the query in a non-UA style sheet, it does nothing. The full implementation is available behind a pref (layout.css.prefers-contrast.enabled) in about:config. If that gets flipped, then we'll parse and react appropriately in all style sheets. Does that make more sense? Ultimately, we'd like to do away with the pref entirely and have prefers-contrast on by default (so all users can benefit, not just those that are savvy enough to go into about:config and flip it themselves), but we're waiting for a resolution here.
The CSS Working Group just discussed forced-colors and prefers-contrast
.
What the difference is between using @media (forced-colors: active) { }
and @media (prefers-contrast: forced) { }
? It seems there is no difference.
So why is it easier for Authors to have two ways to write the same code? Sure, they will often be conceptually thinking about contrast and forced colors at the same time — along with light/dark mode, reducing transparency, reducing motion... but that doesn't mean we should try and put all these media queries together into one. Media queries have the power of nesting, AND, OR, etc, so Authors can combine them however they want.
As I spent some time after the CSSWG discussion digging into this a bit more, and came to the opinion that we either need to remove forced
from prefers-contrast
— or we need to get rid of the forced-colors
media query altogether. Having both makes this too complicated for Authors.
In other words, we have three options:
forced
from prefers-contrast
forced-colors
media queryNo matter which path we choose, the three options all end up with the same capabilities for Authors — the same usecases and needs are met. It's really a matter of: a) what implementors are willing to do; b) what's best for Authors.
I much prefer removing forced
from prefers-contrast
. That makes more sense to me. It feels more simple. It also does not require Edge to agree to unship the forced-colors media query. (No one has shipped prefers-contrast yet.)
Having two ways to write effectively the same media query conditional, when all this is already complicated (the user preference options on different OSes are very different & most Authors only have access to one)... having two ways to write the same code will only going to result in making Authors think these tools are even more complicated than they actually are.
Florian argued:
When responding to forced-colors, it can be useful for an author to do the same contrast adjustments, reducing clutter and such (so summarized in the minutes)
...so therefore having both situations in one media query will be easier for Authors.
I disagree. I think it's confusing — Authors will wonder what the difference is between using @media (forced-colors: active)
and @media (prefers-contrast: forced)
. [Answer: none].
They may very well want to do similar things in the code, but these are separate situations that have to be thought through. Plus, prefers-reduced-transparency
, prefers-reduced-motion
, and prefers-color-scheme
will all come into play. A designer should think about reducing transparency, adjusting things for a high/low contrast, reacting to forced colors, and light/dark mode all at once. Having two of these overlap in a mysterious way (for no reason other then theoretical code efficiency) doesn't make things easy for Authors — it makes it harder.
It is true that for Implementors these two things are tightly connected. Forced colors does often trip prefers-contrast high or low (not always, depends on the color theme). But Authors won't be thinking about it this way. For them, forced colors is one thing. Prefers high or low contrast is another. Exposing browser engine complexity to Authors doesn't help them.
I see in the minutes the argument being raised that Authors will want to reduce visual complexity for both forced colors and for low/high contrast, so why not put it all in one MQ. To me that's like saying people will want to do things for phones, so why make them think through when to use a MQ for screen size vs a MQ for reduced-data? Let's just put the new prefers-reduced-data
values into width
, so Authors can use them at the same time.
What the difference is between using
@media (forced-colors: active) { }
and@media (prefers-contrast: forced) { }
? It seems there is no difference.
There's no difference indeed.
So why is it easier for Authors to have two ways to write the same code?
It's not easier. I'm arguing for both because one of them shipped already so we cannot remove it (at least not easily), and because I see benefits in the other one.
I see in the minutes the argument being raised that Authors will want to reduce visual complexity for both forced colors and for low/high contrast, so why not put it all in one MQ. To me that's like saying people will want to do things for phones, so why make them think through when to use a MQ for screen size vs a MQ for reduced-data? Let's just put the new prefers-reduced-data values into width, so Authors can use them at the same time.
My point is different in a subtle but important way: I don't want to group them so that authors can target all of these users with one query, but because I expect authors will write code that is applicable to all these users with that one query anyway, and asking authors to specifically remember to target a separate small demographic that would be well served by code they already wrote is unfortunate, because some/most of the time they'll forget, and these users will miss out.
In more details:
@media (prefers-contrast: more)
-> yes@media (prefers-contrast: less)
-> yes@media (prefers-contrast)
-> yesWhen that happens, this common code will be applied to:
The question is then: should it also apply to users who have picked a forced color scheme that is neither particularly high nor low contrast, or should we require authors to specifically remember that these people exist and to target them explicitly.
I'm saying that yes, it should apply, because the shared code is highly likely to be relevant, and authors are overall unlikely to remember to carter for this this relatively small user demographic. Those who do remember still have all the tools needed to tailor the style if a difference is needed, but getting things to work when you don't think about it too much has value. Accessibility gets better when users with similar enough needs are grouped together so that they benefit even when authors don't specifically remember them.
I do agree that from a conceptual point of view, forced colors and contrast preferences are different things, and it would be cleaner to have them be separate, which probably affect teachability. So there's a tradeoff. @jensimmons argues that we should pick author understandability over implementer convenience, and this calls for keeping forced-color: active
over prefers-contrast: forced
. I completely agree. But I think there are user benefits here that could outweigh the author concerns, and that this calls for the other way around.
As I understand them, all commenters in the meeting and on the GitHub issue are in agreement that either syntax can provide the same functionality and implementability. The disagreements are purely a difference of opinion about the ideal authoring usage.
Most also agree that we should keep forced-colors
so the main question is whether to keep prefers-contrast: forced
.
As I understand them, these are the main arguments made in favor of keeping prefers-contrast: forced
:
@media (prefers-contrast)
as opposed to @media (prefers-contrast) or (forced-colors)
.less
(reduced contrast) or more
(increased or high contrast). The follow-on justification for this (if I understand correctly) is the premise that ~"all users who have either forced colors or any contrast preference will also have a desire for reduced visual complexity, such as removing decorative background patterns."The main arguments I and others made against prefers-contrast: forced
:
forced-colors
for interoperability, unless the new syntax proposal provides sufficient benefit to warrant deprecating existing implementations. In my opinion, it doesn't provide additional benefit. (More on that below, since it's the primary point of disagreement.)prefers-contrast
is only ever about a preference for more or less contrast. forced-colors
is only about whether colors are forced, regardless of contrast.So as I see it, the primary argument in for keeping prefers-contrast: forced
is based on a causation versus correlation fallacy.
There is an assumption that all people with forced colors want some form of reduced complexity. I don't believe this to be true, and I haven't seen any evidence presented to prove this assumption.
There's no disagreement on the above two statements, and both of those relate to a contrast preference. But those aren't the justification for keeping prefers-contrast: forced
. Instead the argument is this:
Premise: If users have custom colors whose contrast ratios match neither low contrast nor high contrast, every user in this group still wants reduced visual complexity. (???)
I do not believe this ↑ premise is true. My gut feeling is that it's not true. I would assume this group of users just prefer to theme their Windows experience, and don't care about reduced complexity at all. Regardless, we don't know enough about this group of users to prove or disprove either assumption.
In my opinion, if CSS needs a media feature for prefers-reduced-complexity
or prefers-improved-legibility
, the working group should consider those separately.
I think @cookiecrook 's summary in https://github.com/w3c/csswg-drafts/issues/5433#issuecomment-716954048 and https://github.com/w3c/csswg-drafts/issues/5433#issuecomment-716954108 is a good one, and I agree that the tension summarized there is the core of the argument to be settled, either by picking a point on the trade-off, or by disproving some of the assumptions, thereby doing away with the trade-off. I'd just add one small nuance:
all users who have either [....]
I don't think we need to go as far as "all users". With "most users", the argument still works, as including prefers-contrast: forced
would help more often than not. There's a statistical nature to this problem, and depending on how we set up the system, we're may help or inconvenience more people.
Which leads us to
Premise: If users have custom colors whose contrast ratios match neither low contrast nor high contrast, every user in this group still wants reduced visual complexity. (???)
Same here: I'd replace "every user" with "most users". And while I agree the statement with "every" might be a little hard to prove or dubious, it seem much less of a stretch when it's merely "most": when you've opted into a forced (and thus reduced) color palette, you no longer have room for all sorts of decorative things, from a variety of background images, to gradients, or all sorts of embellishments. By picking a forced palette, you're necessarily opting into a visual simplification of some kind. It's going to happen whether we tell the author through a MQ or not, but it's part of the package, so we might as well tell them, so that they can react.
I think my argument stands even if we change the instances of “every/all users” to “most users.” I don’t know of any evidence that indicates “most” want this.
Rather than requesting we disprove the assumption, can someone point to evidence that confirms the assumption?
We didn't get to this in the F2F last week, but I agree with the core of @cookiecrook's argument - I don't think there is strong evidence for the boolean form of prefers-contrast
being used to reduce visual complexity, and would probably be difficult for authors to reason about (enhancement in service of respecting a user preference is much different from adjusting in response to forced changes to a page's appearance).
As anecdata, I also ran across this blog post that expresses some of the same sentiments: https://kilianvalkhof.com/2021/css-html/prefers-contrast-forced-is-a-mistake/
Also, if this does become a larger problem in practice, we would have the option of re-adding the value, whereas removing it would be more difficult. Another option (either now, or if the boolean usage ends up being problematic) would be always mapping forced colors mode to more
or less
, similar to what is done for prefers-color-scheme
.
FYI @astearns added this on the agenda for tomorrow's CSS meeting at your local time.
Going to gather some data on user-set (or platform-inhereted) contrast ratios in firefox :)
The CSS Working Group just discussed [mediaqueries-5] duplication of `forced-colors: active` and `prefers-contrast: forced`
, and agreed to the following:
RESOLVED: Removed the forced value from prefers-contrast MQ
Fixed through https://github.com/w3c/csswg-drafts/commit/a2f6a35c4abf8f1accc9459c14b55d4cd25748b0 (and https://github.com/w3c/csswg-drafts/commit/d7b7f4b9a6445ef9390fd3f68ed7cf57efe4dd54 for typos), so closing.
@cookiecrook, I'd appreciate if you could confirm being satisfied with this edit.
Note APA is just waiting for signoff from @cookiecrook before closing in our tracker.
@frivoal Just seeing this, but I don't see a unified PR linked. PR review assignments are usually the way I would spot these.
Is https://github.com/w3c/csswg-drafts/commit/a2f6a35c4abf8f1accc9459c14b55d4cd25748b0 the only substantive diff?
@frivoal?
@cookiecrook we had a resolution, so I went ahead without a pull request. https://github.com/w3c/csswg-drafts/commit/a2f6a35c4abf8f1accc9459c14b55d4cd25748b0 is indeed the only substantive commit. I'll respond to your two comments.
[mediaqueries-5] duplication of
forced-colors: active
andprefers-contrast: forced
Breaking this discussion out of the large mega thread in #2943.
I believe these statements are true.
forced-colors: active
andprefers-contrast: forced
are exact duplications of each other.forced-colors
is already implemented in Edge (and possibly in the Chrome HC extension.)Opinions:
forced
value is intended as a replacement for theforced-colors
media feature, and I've also heard that these are intended to be complementary and co-exist. Which is it, and why?forced
value intoprefers-constrast
is unnecessarily limiting. Another platform (iOS, Mac, ChromeOS, Android, Linux) may support a different forced mode in the future, andforced-colors
would be easier to extend.Editorial:
prefers-contrast: forced
cross-link toforced-colors: active
an confirms the duplication. If both are kept, the reciprocal link and explanatory prose should be added, too.