- From: andruud via GitHub <sysbot+gh@w3.org>
- Date: Fri, 21 Aug 2020 07:56:36 +0000
- To: public-css-archive@w3.org
> Currently it's not undefined, it just doesn't do what you probably want, as it subs in the literal keyword "inherit" which is almost never valid. That's a good point. I'm not sure why I thought it was undefined. :upside_down_face: > if it's okay implementation-wise Like you say we're already required to support this behavior via IACVT. The exception is revert at computed-value time, which is _no longer_ required by anything else after the recent edit to css-color-adjust-1. So `var(--unknown, revert)` would be the new reason for why impls must support revert at computed-value time. Bummer. > We have to be a little stricter that this only occurs if the var() is the sole value of the property - is that okay? Should be OK, but why is that necessary to specify? Can't we just handle the CSS-wide keyword if we somehow end up with it? E.g. `display: var(--unknown, inherit) var(--also-unknown, )` would substitute to `display:inherit` (whitespace omitted) and could therefore trigger inherit-behavior? Seems easier to handle this as "after substitution, try to parse a CSS-wide keyword and handle it as such if successful". -- GitHub Notification of comment by andruud Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5325#issuecomment-678101411 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 21 August 2020 07:56:38 UTC