When we originally wrote the spec for 'color-scheme', we anticipated a larger spread of user preference options than turned out to actually exist: we anticipated that a user could express a notion of "no preference" or of "overriding preference", in addition to a "normal" preference. This is then combined with color-scheme's ability to express either support or sole support (via the only keyword). We then dance back and forth with preference levels: we take the user's preference, unless the page only supports a different preference, unless the user has an overriding preference, unless the page has sole support (in which case we "override" in a way similar to Forced Colors Mode to match that support).
But in practice, none of this has panned out, in the many years since color schemes have been supported. OSes and UAs, in practice, just support two possible preference values: light, or dark. And without a preference strength, the distinction between support and sole support doesn't exist.
Supporting all of this in the spec makes the algorithms a little complicated to understand and reason about. It would be a lot easier if a color scheme preference was just light or dark, and support was just a list of schemes you support. Then matching a preference against a support is just a matter of returning the pref if it's in the support list, otherwise returning the first value in the support list, or the browser default if there is no support list.
This doesn't lose us anything in practice. Do we anticipate any UAs actually ever supporting these values? If not, can we remove the concepts from the spec, and mark only as a supported but meaningless legacy keyword?
When we originally wrote the spec for 'color-scheme', we anticipated a larger spread of user preference options than turned out to actually exist: we anticipated that a user could express a notion of "no preference" or of "overriding preference", in addition to a "normal" preference. This is then combined with
color-scheme's ability to express either support or sole support (via theonlykeyword). We then dance back and forth with preference levels: we take the user's preference, unless the page only supports a different preference, unless the user has an overriding preference, unless the page has sole support (in which case we "override" in a way similar to Forced Colors Mode to match that support).But in practice, none of this has panned out, in the many years since color schemes have been supported. OSes and UAs, in practice, just support two possible preference values: light, or dark. And without a preference strength, the distinction between support and sole support doesn't exist.
Supporting all of this in the spec makes the algorithms a little complicated to understand and reason about. It would be a lot easier if a color scheme preference was just light or dark, and support was just a list of schemes you support. Then matching a preference against a support is just a matter of returning the pref if it's in the support list, otherwise returning the first value in the support list, or the browser default if there is no support list.
This doesn't lose us anything in practice. Do we anticipate any UAs actually ever supporting these values? If not, can we remove the concepts from the spec, and mark
onlyas a supported but meaningless legacy keyword?