[css-variables] CSS-wide keywords in fallbacks

[andruud]

Suppose we have: div { display: var(--undefined,inherit); }

The cascaded value for display is in this example a sequence of tokens (not a CSS-wide keyword), hence the explicit defaulting behavior in the cascade is not triggered. At computed-value time, the var() substitutes to inherit. This is valid per css-values which states that the grammar of all properties are understood to also allow unset | initial | (etc). This means we end up with a valid value of inherit that we somehow have to deal with computed-value time.

It seems useful to be able to use CSS-wide keywords in the fallback, especially with revert. We should consider specifying that if a declaration ends up with a CSS-wide keyword after var() substitution, it's resolved at computed-value time similarly to how it's normally done cascade-time. (I'll just have to think about whether this triggers any of the Bad Stuff from #4155).

Or failing that, make it IACVT, but we shouldn't leave it undefined.

[andruud]

@tabatkins Do you have any thoughts on this?

[tabatkins]

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 said, if it's okay implementation-wise, I'm fine with triggering the other global-keyword behaviors, since we can already trigger inherit/initial via IACVT. We have to be a little stricter that this only occurs if the var() is the sole value of the property - is that okay?

It would also mean that there's some behaviors that are only obtainable via var() fallback, not as the value of a variable. To get a variable to be able to contain global keywords, we'd have to do some minor hackery; I don't think it's that important, but still.

I suppose that's already true with things like subbing in another variable's value for the fallback; to get this behavior as a first-class value, we'd need to add delayed evaluation for variables. I have a proposal for that tucked away, but I don't think it's worth bringing out right now, and anyway, it won't interfere with resolving this issue in the simple way.

[andruud]

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. 🙃

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".

[emilio]

Seems easier to handle this as "after substitution, try to parse a CSS-wide keyword and handle it as such if successful".

This is what Gecko does, afaict.

[tabatkins]

Ah yeah, that works.

So since we're at CR, Agenda+ to ask about this.

Also, uh, to republish, since it's been 5 years.

[css-meeting-bot]

The CSS Working Group just discussed [css-variables] CSS-wide keywords in fallbacks, and agreed to the following:

• RESOLVED: Using initial value as fallback of var triggers initial value behavior assuming that the property only has that keyword because of substitution

The full IRC log of that discussion

<dael> Topic: [css-variables] CSS-wide keywords in fallbacks
<dael> github: https://github.com//issues/5325
<dael> TabAtkins: Another by andrers. Started out confused by behavior of css wide keyword like initial in fallback of var. Css wide keywords are handled very early in process. Once variables substitute it's later. Using initial subs in the keyword initial which is usually invalid. It's not using the initial machinery
<dael> TabAtkins: WE've apparently always had behavior that if you use css-wide keyword as a fallback we'll trigger the appropriate behavior. emilio suggests FF has also always had that.
<dael> TabAtkins: Reasonably useful behavior. B/c everyone is already doing it I don't see harm in spec. Using initial value as fallback of var triggers initial value behavior assuming that the property only has that keyword because of substitution
<dael> Rossen_: Reasonable
<dael> Rossen_: Additional thoughts or reasons why we shouldn't have variables with initial value behave that what?
<dael> fantasai: That's impl for revert? THe rest handles at computed but revert is cascade time
<dael> TabAtkins: No more or less than a prevoius item we did which also triggered revert for forced-colors. It makes anders a lttle sad
<dael> fantasai: If we can rollback cascade why can't we reat invalid values at declaration
<dael> TabAtkins: Big difference than doing this annoying thing when authors ask and doing it any time a variable is invalid
<dael> fantasai: I think handling other keywords is fine, if revert is impl it's great. Would also be nice to allow revert to previous declaration.
<AmeliaBR> What happens if the keyword isn't the only value of the property? `border: pink var(--line-width); --line-width: inherit` Does the whole thing get the invalid / unset behavior, or an inherit behavior?
<dael> fantasai: I would like to make sure all impl can handle revert because specing it works.
<dael> TabAtkins: I believe that's not something we handle separate. Right now none of the keywords are. All except perhaps revert work in implementations even if revert is harder.
<dael> fantasai: Works for me. I would like revert to work but want to make sure it does before we spec
<dael> Rossen_: Sounds like fantasai is on board.
<dael> Rossen_: Objections?
<dael> RESOLVED: Using initial value as fallback of var triggers initial value behavior assuming that the property only has that keyword because of substitution

[Loirooriol]

fantasai: Works for me. I would like revert to work but want to make sure it does before we spec

@fantasai revert as a fallback is implemented in Firefox. Chromium currently treats it as unset (source code). Testcase.

[andruud]

Chromium currently treats it as unset

That was done as temporary behavior pending the outcome of this discussion. Supporting it in Chromium should be easy.