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

Re: [csswg-drafts] [css-color-adjust-1] Is forced color computed or used value? (#4915)

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
Message-ID: <issue_comment.created-714624132-1603385446-sysbot+gh@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>
&lt;emilio> topic: [css-color-adjust-1] Is forced color computed or used value?<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/4915#issuecomment-701674628<br>
&lt;emilio> fantasai: I reopened in light on the resolutions we took to adopt fremy's proposal in the previous issue<br>
&lt;emilio> ... we decided than rather than a cascade-time revert and consider them out-of-gamut for non-system colors<br>
&lt;emilio> ... which is a different technique<br>
&lt;emilio> ... but out-of-gamut mapping is a used-time op, not computed-time<br>
&lt;emilio> ... by doing it at computed-value time we got weird behavior wrt ??<br>
&lt;emilio> s/??/inheritance<br>
&lt;emilio> fantasai: when you do it at computed value then it'll change it to system color and then inherit<br>
&lt;emilio> ... if you have a forced-color-adjust: none section down the page<br>
&lt;emilio> ... expecting a particular inherited color<br>
&lt;emilio> ... but instead you get a random system color which might be unreadable<br>
&lt;emilio> ... if we do this mapping at used value time<br>
&lt;florian> q+<br>
&lt;emilio> ... then it inherits the color properly<br>
&lt;fremy> q+<br>
&lt;emilio> ... but the ancestor with forced colors will get the system color at used value time<br>
&lt;emilio> q+<br>
&lt;emilio> TabAtkins: I think I agree on this, makes much more sense<br>
&lt;TabAtkins> s/think I/strongly/<br>
&lt;emilio> Rossen_: it also avoids the dependency with color-mix()<br>
&lt;florian> q-<br>
&lt;emilio> fantasai: yeah prevents all the interpolation / transitions issues<br>
&lt;Rossen_> ack fremy<br>
&lt;emilio> fremy: I think it does make a lot of sense but I want to make sure something is recorded<br>
&lt;emilio> ... if you have a disabled button, the default style will have some color<br>
&lt;emilio> ... let's say `text` -> `disabledtext`<br>
&lt;emilio> ... so it can be made at used value time<br>
&lt;emilio> ... but for children you need to walk the parent chain to know which color to reset<br>
&lt;emilio> ... basically what you map to depends on the UA stylesheets<br>
&lt;emilio> ... so you kinda need to remember this in a way<br>
&lt;emilio> florian: [restates the issue]<br>
&lt;emilio> TabAtkins: it is indeed a separate concern<br>
&lt;emilio> fremy: I wanted to make sure it's mentioned because it's an important impl detail<br>
&lt;emilio> fantasai: Yeah we should note that in the spec<br>
&lt;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>
&lt;Rossen_> q<br>
&lt;Rossen_> ack emilio<br>
&lt;fantasai> emilio: Wanted to mention related point<br>
&lt;fantasai> emilio: this is a problem, even if you don't account for children<br>
&lt;fantasai> emilio: if you specify color on the button<br>
&lt;fantasai> emilio: in order to know what to revert to, need to do the cascade again<br>
&lt;fantasai> emilio: to find the original value to revert to<br>
&lt;fantasai> emilio: that would be my main concern<br>
&lt;fantasai> emilio: I think it could be addressed with something like an internal CSS property<br>
&lt;fantasai> emilio: but different from what browsers currently do<br>
&lt;fantasai> fremy: similar to :visited<br>
&lt;fantasai> emilio: similar, but different<br>
&lt;fantasai> fremy: this is what Edge did, we tracked a separate value<br>
&lt;fantasai> s/value/value for :visited<br>
&lt;fantasai> Rossen_: We had a cascaded value alongside, for anything that was overridden, so that we didn't have to go and recascade<br>
&lt;fantasai> Rossen_: we would have it at hand, ready to use as needed.<br>
&lt;fantasai> Rossen_: Added a little bit of memory, but relatively insignificant<br>
&lt;fantasai> Rossen_: so from impl pov, this is very doable, not much additional context needed<br>
&lt;fantasai> Rossen_: but fremy's point that it's not automatic is relevant<br>
&lt;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

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