- From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
- Date: Tue, 11 Aug 2020 23:19:11 +0000
- To: public-css-archive@w3.org
AmeliaBR has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color-adjust] Clarify expectations re forced-color mode, system colors, and transitions == In #5342 we agreed that the `forced-color-adjust` property should not be animatable, as it has too many side effects on the computed values of other properties. But since [forced color mode and `forced-color-adjust`](https://drafts.csswg.org/css-color-adjust/#forced) do have effects on other properties, it should be clarified how those changes should impact transitions on those other properties. Per spec, transitions apply to [changes in the computed value](https://drafts.csswg.org/css-transitions-1/#transitions). That means, for example, that if a property is set to `currentcolor`, it will not transition if the `color` property is changed (although if the `color` property is transitioned itself, that will flow through to the second property). I've confirmed that both Chromium and Firefox behave this way. As browsers switch to treating the system color keywords as inheritable computed values, I would expect the same behavior — meaning, if a property is set to a system color, and the used values of the system colors change because of forced color mode being turned on, there would be no expectation of a transition. However, if the property initially had a regular color value, and forced color mode triggered the various `revert` rules to switch to system colors, that would be a change in computed value which would normally trigger transitions. As Rossen noted on the call, “turning on forced color mode” is often an OS-level reset operation, so implementing it as a CSS transition would be difficult. (Also, we don't currently have a syntax for describing the interpolation between two colors when one of them is a system color keyword — it would require the [CSS Colors 5 color-mix function](https://drafts.csswg.org/css-color-5/#color-mix).) Then there is the case that I brought up on the call: what if the author turns `forced-color-adjust` on or off on a particular sub-tree? E.g., maybe while text is being edited, it uses the forced colors, but when it loses focus some special syntax highlighting kicks in. Or a “pressed” state of a button requires forced-color overrides, but the normal button state uses the forced system button colors. Again, these are changes in the computed value of the color properties, which would normally trigger transitions. Turning forced colors on/off is a rare event, and controlled by the user, so maybe it's best to treat it as a complete reset, just to make sure it's done cleanly. But in the case of toggling `forced-color-adjust`, the changes are controlled by the author, who will presumably be testing the change. I don't think it's an important use case to be able to transition these changes, so it really comes down to which behavior is simpler / most consistent from an implementation perspective — which is worse, not transitioning on changes in computed value, or needing to handle the special cases for things like background color, where the computed value isn't cleanly defined in forced color mode? The most important thing, IMO, is that there is consistent behavior cross-browser, so that we don't end up with authors relying on behavior from one browser that is difficult to implement elsewhere. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5419 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 11 August 2020 23:19:13 UTC