Closed andruud closed 2 years ago
In other words, the global keywords should be replaced with a value before being compared?
I mean that style(left: revert[-layer])
should be a parse error or "unknown" or something like that.
Actually, that might not be enough, since you can also do style(left: var(--x, revert))
.
@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?
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.
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.
+1 to disallowing the css-wide keywords, at least the ones requiring cascading
Given that we resolve em
s 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:
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?
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.
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…)
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 term "cascade-dependent keyword" is now defined for you to use, @mirisuzanne
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. 😂
Correct. ^_^
Drafted in bb594b71d
The spec currently says that queried values must be computed in the context of the container, so I assume things like
style(left: 1em)
andstyle(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
andrevert-layer
would require cascading-information that is long gone by the time we reach the descendant affected by the query.