- From: fantasai via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Mar 2022 16:25:27 +0000
- To: public-css-archive@w3.org
OK, I reread the entire conversation. Arguments for resolving system colors at computed value time: - There's an argument that switching `color-scheme` shouldn't cause system colors to change when they inherit through. I disagree with this argument. I don't think the proposed behavior is more reasonable, why would you change `color-scheme` if you are not wanting the color scheme to actually change and are prepared for that? - There's an argument that managing computed values that are linear combinations of, potentially, 18 different channels is unweildy. I take this argument as valid. Arguments for resolving system colors at used value time: - There's an argument that `forced-color-adjust: none` should actually turn off the effect of forced colors within that element. Giving a subtree an unexpected mix of forced and unforced colors can cause contrast problems. What it boils down to for authors is: * If we compute to absolute colors, authors using `forced-color-adjust: none` have to explicitly set every inherited color property on that element to their own chosen color, or the element could have unreadable contrast. They have to know that forced colors mode on an ancestor will break color inheritance into this element, and compensate for that by redeclaring any such colors on the element using `forced-color-adjust: none`. * If we resolve at used-value time, authors need to know not to change `color-scheme` unless they're actually changing their color scheme. Which seems... obvious? -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6773#issuecomment-1069295596 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 16 March 2022 16:25:29 UTC