- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 22 Oct 2020 16:50:47 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-color-adjust-1] Is forced color computed or used value?`, and agreed to the following: * `RESOLVED: Forced colors happens at used value time. Add a note to the spec about implementation` <details><summary>The full IRC log of that discussion</summary> <emilio> topic: [css-color-adjust-1] Is forced color computed or used value?<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/4915#issuecomment-701674628<br> <emilio> fantasai: I reopened in light on the resolutions we took to adopt fremy's proposal in the previous issue<br> <emilio> ... we decided than rather than a cascade-time revert and consider them out-of-gamut for non-system colors<br> <emilio> ... which is a different technique<br> <emilio> ... but out-of-gamut mapping is a used-time op, not computed-time<br> <emilio> ... by doing it at computed-value time we got weird behavior wrt ??<br> <emilio> s/??/inheritance<br> <emilio> fantasai: when you do it at computed value then it'll change it to system color and then inherit<br> <emilio> ... if you have a forced-color-adjust: none section down the page<br> <emilio> ... expecting a particular inherited color<br> <emilio> ... but instead you get a random system color which might be unreadable<br> <emilio> ... if we do this mapping at used value time<br> <florian> q+<br> <emilio> ... then it inherits the color properly<br> <fremy> q+<br> <emilio> ... but the ancestor with forced colors will get the system color at used value time<br> <emilio> q+<br> <emilio> TabAtkins: I think I agree on this, makes much more sense<br> <TabAtkins> s/think I/strongly/<br> <emilio> Rossen_: it also avoids the dependency with color-mix()<br> <florian> q-<br> <emilio> fantasai: yeah prevents all the interpolation / transitions issues<br> <Rossen_> ack fremy<br> <emilio> fremy: I think it does make a lot of sense but I want to make sure something is recorded<br> <emilio> ... if you have a disabled button, the default style will have some color<br> <emilio> ... let's say `text` -> `disabledtext`<br> <emilio> ... so it can be made at used value time<br> <emilio> ... but for children you need to walk the parent chain to know which color to reset<br> <emilio> ... basically what you map to depends on the UA stylesheets<br> <emilio> ... so you kinda need to remember this in a way<br> <emilio> florian: [restates the issue]<br> <emilio> TabAtkins: it is indeed a separate concern<br> <emilio> fremy: I wanted to make sure it's mentioned because it's an important impl detail<br> <emilio> fantasai: Yeah we should note that in the spec<br> <emilio> florian: if we were doing it at computed value time you wouldn't have to do it so it's the same issue, not separate<br> <Rossen_> q<br> <Rossen_> ack emilio<br> <fantasai> emilio: Wanted to mention related point<br> <fantasai> emilio: this is a problem, even if you don't account for children<br> <fantasai> emilio: if you specify color on the button<br> <fantasai> emilio: in order to know what to revert to, need to do the cascade again<br> <fantasai> emilio: to find the original value to revert to<br> <fantasai> emilio: that would be my main concern<br> <fantasai> emilio: I think it could be addressed with something like an internal CSS property<br> <fantasai> emilio: but different from what browsers currently do<br> <fantasai> fremy: similar to :visited<br> <fantasai> emilio: similar, but different<br> <fantasai> fremy: this is what Edge did, we tracked a separate value<br> <fantasai> s/value/value for :visited<br> <fantasai> Rossen_: We had a cascaded value alongside, for anything that was overridden, so that we didn't have to go and recascade<br> <fantasai> Rossen_: we would have it at hand, ready to use as needed.<br> <fantasai> Rossen_: Added a little bit of memory, but relatively insignificant<br> <fantasai> Rossen_: so from impl pov, this is very doable, not much additional context needed<br> <fantasai> Rossen_: but fremy's point that it's not automatic is relevant<br> <emilio> RESOLVED: Forced colors happens at used value time. Add a note to the spec about implementation<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4915#issuecomment-714624132 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 22 October 2020 16:50:49 UTC