[css-contain-3] CSS-wide keywords in style()

[andruud]

The spec currently says that queried values must be computed in the context of the container, so I assume things like style(left: 1em) and style(left: var(--x)) should work. But the spec does not say anything about CSS-wide keywords, and I think they should be explicitly disallowed.

In particular, satisfying revert and revert-layer would require cascading-information that is long gone by the time we reach the descendant affected by the query.

[mirisuzanne]

In other words, the global keywords should be replaced with a value before being compared?

[andruud]

I mean that style(left: revert[-layer]) should be a parse error or "unknown" or something like that.

[andruud]

Actually, that might not be enough, since you can also do style(left: var(--x, revert)).

[mirisuzanne]

@andruud My sense is that all of these examples would already return a consistent false condition given the current spec text - since keywords/variables can't be replaced in the query which is outside the cascade (initial might be an exception?), and both would be replaced with a computed value on the element.

Am I right that you're basically just asking to make that existing behavior explicit, so we can consider this a parse error instead of attempting the query?

[andruud]

That's a good point for the CSS-wide keywords. They primarily only do something if they're the 'cascaded value', which they won't be here. (Looks like there's no exception for initial).

The same can not be said for e.g. var(--x, revert), which does something computed-value time. But if you already think that var() is not allowed, then I guess there's no problem there.

I think it's a good idea to make the existing behavior explicit, as it was not obvious to me for from the spec language. In particular the part which says that values are "computed with respect to the container".

Perhaps we can somehow specify that for style(foo: value), value must match the "actual"/"core" grammar of foo. And by "actual" grammar, what I mean is, if e.g. we look at the grammar for width:

auto | <length-percentage> | min-content | max-content | fit-content(<length-percentage>)

Nothing in there allows for var(), but we generally allow it anyway when we are parsing a declaration. Should probably explicitly say that this is not the case here.

[mirisuzanne]

Oh, if it's possible we can be resolving keywords/variables in both places using the container as a reference, this maybe needs more consideration. I wonder if @fantasai has thoughts on this.

[fantasai]

+1 to disallowing the css-wide keywords, at least the ones requiring cascading

[tabatkins]

Given that we resolve ems and the like, I don't see how var() is problematic - they resolve at the same time. (Technically, var()s are even earlier than ems.)

Agree that disallowing the CSS-wide keywords syntactically is fine, with them specified to resolve to false if they show up anyway (such as via a variable).

fantasai and I think the reasonable options here are:

• disallow all css-wide keywords
• disallow all except 'initial', allows 'initial' for author convenience since it's just an alias for some other existing property-specific value
• disallow all except 'initial' and 'inherit', because these can compute without re-cascading, and asking "is the property the same computed value as its parent" might be useful

[andruud]

var() is indeed not substantially more problematic than em, and initial/inherit/unset should also be fine.

Should we invent a new classification for revert[-layer] (e.g. "cascade-dependent keywords"), and disallow those?

[tabatkins]

Yeah, that sort of categorization probably makes sense for us to lean on elsewhere, like when we split "tree-abiding pseudo-elements" apart from the rest.

[mirisuzanne]

I'll start working on those spec changes (in both cascade and contain). Agenda+ to get a resolution for defining "cascade-dependent keywords" (revert & revert-layer) and disallowing them in style queries.

(I imagine that first part might be editorial, as it doesn't change any behavior on its own? Not sure which level of cascade I should target for that, 5 or 6…)

[css-meeting-bot]

The CSS Working Group just discussed CSS-wide keywords in style(), and agreed to the following:

• RESOLVED: Make cascade-dependent keywords revert/revert-layer disallowed in style() queries
• RESOLVED: other css-wide keywords (initial, inherit, reset) are allowed

The full IRC log of that discussion

<fantasai> subtopic: CSS-wide keywords in style()
<fantasai> github: https://github.com//issues/7080
<fantasai> miriam: when we're doing style queries, question is how are CSS-wide keywords handled as values in the query
<fantasai> miriam: Comparing that to computed value of the property
<fantasai> miriam: Conversation is landing on, there are 2 different types of CSS-wide keywords and maybe want to handle differently
<fantasai> miriam: cascade-dependent keywords like revert and revert-layer, should be disallowed entirely
<fantasai> miriam: but initial and inherit could be supported
<fantasai> miriam: so wanted to distinguish these types in Cascade spec
<fantasai> miriam: and say in Container Queries spec that one is supported and other not
<Rossen_> q?
<fantasai> miriam: that's the proposal here
<fantasai> TabAtkins: I'm in favor
<fantasai> fantasai: me too
<fantasai> TabAtkins: On the implementer side, Anders seems fine with this as well
<fantasai> PROPOSAL: Make cascade-dependent keywords revert/revert-layer disallowed in style() queries
<fantasai> RESOLVED: Make cascade-dependent keywords revert/revert-layer disallowed in style() queries
<fantasai> PROPOSAL: other css-wide keywords (initial, inherit, reset) are allowed
<fantasai> RESOLVED: other css-wide keywords (initial, inherit, reset) are allowed

[tabatkins]

The term "cascade-dependent keyword" is now defined for you to use, @mirisuzanne

[simevidas]

RESOLVED: other css-wide keywords (initial, inherit, reset) are allowed

That must be unset instead of reset. For a second I thought I missed the addition of another CSS-wide keyword. 😂

[tabatkins]

Correct. ^_^

[mirisuzanne]

Drafted in bb594b7