W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2020

Re: [csswg-drafts] [css-color-adjust-1] more granular overriding of forced colors mode than per-element (#4178)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 19 Aug 2020 16:25:02 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-676527581-1597854300-sysbot+gh@w3.org>
The CSS Working Group just discussed `[css-color-adjust-1] more granular overriding of forced colors mode than per-element`, and agreed to the following:

* `RESOLVED: System colors will be accepted as specified, everything else is forced`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-color-adjust-1] more granular overriding of forced colors mode than per-element<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/4178<br>
&lt;dael> Rossen_: We discussed in the past. Brought back as another discussion.<br>
&lt;dael> Rossen_: What seems to be agreement on path forward.<br>
&lt;dael> TabAtkins: Summary: We keep the current behavior with a propoerty to turn off forced color adjust for an element. To handle more flexibility w/o negating meaning of forced colors we spec any system colors from author are respected, even if algo wouldn't choose them<br>
&lt;dael> TabAtkins: People can manually use canvas-text etc in way that should make sense so you can make a graph with definitely distinct colors w/o choosing specific colors<br>
&lt;fremy> q+<br>
&lt;dael> TabAtkins: Allow a bit of flexibility as long as authors stick to system we won't mess with them<br>
&lt;dael> AmeliaBR: I think this has best end result for encouraging good behavior by authors while having authoring simplicity<br>
&lt;dael> AmeliaBR: We want authors who are customizing forced color mode to use system colors and recognize they don't have full control. Cases where not enough like syntax highlighting. Having option of full manual control is great<br>
&lt;dael> AmeliaBR: Problem comes down to this will throw out any idea we can impl forced color through cascade and revert rules. I think we've had enough exceptions that maybe it's time to rewrite that spec section and define forced colors in way that doens't pretend it's cascade and reversion<br>
&lt;Rossen_> q?<br>
&lt;Rossen_> ack fremy<br>
&lt;Rossen_> q+<br>
&lt;dael> fremy: I am in support of proposal. One question, I think at some point discussed poss in forced color that color funct falls back to named system color. Is that still part of proposal or different issue?<br>
&lt;dael> TabAtkins: Still part of proposal<br>
&lt;dael> fremy: Then I'm totally on board.<br>
&lt;Rossen_> q-<br>
&lt;dael> Rossen_: I'm on queue to support proposal<br>
&lt;dholbert> q+<br>
&lt;dael> Rossen_: Previous conversation was around poss of further ability to relax color spaces people can choose. That was discussion and feature extension to having !override to allow override and use any color<br>
&lt;dael> Rossen_: This proposal is a good first subset of acheiving that so sounds great to me<br>
&lt;Rossen_> ack dholbert<br>
&lt;dael> dholbert: Make sure I understand. Still allows for black text on black bg on some systems depending on forced color. So the system color collides with bg color. Opens poss for text unreadable<br>
&lt;dael> TabAtkins: Yes, if author is using colors that aren't paired but looks okay on their system it can happen. But you can always screw up colors. We'll have suggestion people stick to paired colors.<br>
&lt;dael> Rossen_: Other point there is that since author is taking upon themselves to override with a color choice ideally they will also be making sure the contrasting colors around are chosen in a way that makes sense.<br>
&lt;dael> Rossen_: Just like other features in css we can't prevent horrible experiences but we want good defaults an dprovide override<br>
&lt;dholbert> q-<br>
&lt;Rossen_> q?<br>
&lt;dael> TabAtkins: This is lower chance than accidental unreadablity instead of original proposal to allow any color. I think this is safer but allowing decent level of customization for the author<br>
&lt;dael> Rossen_: Other thoughts or questions?<br>
&lt;dael> Rossen_: If not I'll call for objections<br>
&lt;dael> fantasai: We're prop accept fremy original proposal? You can spec whatever colors and if they're not part of system they're overwritten?<br>
&lt;fantasai> syntax highlighting would have to use `forced-color-adjust: none`<br>
&lt;dael> fremy: Believe so<br>
&lt;dael> fantasai: sgtm<br>
&lt;dael> Rossen_: System colors will be accepted as specified, everything else is forced<br>
&lt;dael> RESOLVED: System colors will be accepted as specified, everything else is forced<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4178#issuecomment-676527581 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 19 August 2020 16:25:04 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:13 UTC