Re: [csswg-drafts] [css-cascade-4] Revert at computed-value time (#4155)

I think I know what we should do now. Allow `revert` at computed-value time as a thing, but specify (if/when necessary) that `forced-color-adjust` becomes _invalid at computed-value time_ if it depends on any property affected by the forced colors mode. This way we don't actually need to compute the value of the invalid dependency, and there isn't an inconsistency.

More generally properties whose computed value affects cascade behavior should be invalid at computed-value time if it depends on things it's affecting in the cascade. So for example, if `direction` somehow managed to depend on `margin-left` (use your imagination for how this could be possible in the future), then `direction` is IACVT because there might be a css-logical property which may or may not resolve to `margin-left`, depending on the computed value of `direction`.

I'm closing this for now, since the crazy scenarios are currently unreachable (and they might stay that way).

@tabatkins Not familiar, but sounds like it would indeed avoid the problem. However, I was under the impression that we wanted a way to disable forced colors for entire subtrees, in which case `!override` doesn't sound very practical?


 - Why cascade `!override` separately if `forced-color-adjust` doesn't exist? If `forced-color-adjust` doesn't exist, we're automatically not depending on computed-value time anymore, so `!override` might as well be a normal priority in the cascade.
 - Cascading multiple values for each property seems like an unsustainable pattern. As @FremyCompany points out we're already doing this in practice for colors, so this would mean we'd now need to cascade _four_ values per color: :visited regular, :visited !override, unvisited regular, unvisited !override). We should IMO avoid this completely.

GitHub Notification of comment by andruud
Please view or discuss this issue at using your GitHub account

Received on Monday, 25 May 2020 09:46:34 UTC