W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2020

Re: [csswg-drafts] [css-variables] CSS-wide keywords in fallbacks (#5325)

From: andruud via GitHub <sysbot+gh@w3.org>
Date: Fri, 21 Aug 2020 07:56:36 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-678101411-1597996594-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:13 UTC