- From: andruud via GitHub <sysbot+gh@w3.org>
- Date: Mon, 24 Aug 2020 08:59:48 +0000
- To: public-css-archive@w3.org
> having forced colors happen "after" transitions check for triggers
Hmm, I think we need to clarify something. There are two (or more) ways of thinking about when/how forced colors "happen":
A) The computed value is produced (and held as _the_ computed value). Then at some point later the computed value is adjusted ("in place") to something else. This means there's effectively two different computed values, and we can choose whether to check for transition triggers before or after the adjustment.
or
B) We _predict_ what the computed value _would be_ had forced colors mode not been enabled ("the original value"), then
either accept that as _the_ computed value (if it's a system color etc), or pick some other value as _the_ computed value. In this case there is only _one_ computed value, and the transition-trigger-check only has one value to choose from.
I think (B) is a better choice (@tabatkins: WDYT?), as having multiple versions of "the computed value" is confusing. So if we want to block transitions from happening, we'd need to do so explicitly.
In Blink, it will actually be more work to _not_ transition the properties, but Rossen's argument makes sense (there might be an OS level reset outside Blink's control), so preventing transitions would probably be simpler overall.
--
GitHub Notification of comment by andruud
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5419#issuecomment-679002425 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 24 August 2020 08:59:50 UTC