Repository navigation
[css-values-5] Disallow mix/random/tree-counting functions in some contexts #10982
Description
Based on comments in #10879, any value defined in CSS Values and Units should be valid in any context other than a property value, unless otherwise specified.
mix, random, tree couting functions, need an element, but are not explicitly disallowed in other contexts.
I would say they should be invalid in media queries and any descriptor value, and valid in the prelude of keyframe and @container rules. (It seems easier to find use cases in the prelude of keyframe rules.)
Perhaps defining the concept of element-dependent (substitution) value could help clarifying this: such value would be invalid in all contexts except those "associated" to an element, or that do not need to resolve its value (feature queries). var(), attr(), toggle(), <whole-value>, would be element-dependent subsitution values.
I do not know if any of these substitution functions should/can be valid in the HTML srcset attribute (to replace <length>), but invalid in the media attribute. I guess none is currently accepted, not even math functions.
Activity
fantasai commentedon Oct 8, 2024
Some types of mix functions are reasonable to allow anywhere, they just represent the interpolation between two values and that's fine. We could also define something reasonable for
random()outside of an element context. Agree with defining some kind of concept for element-dependent functions, though, and making such invalid (if they don't have a reasonable fallback behavior).cdoublev commentedon Oct 9, 2024
Allowing them anywhere would require making some arguments (
<'animation-timeline'>,per-element) invalid in these other contexts.lilles commentedon Mar 14, 2025
I was thinking they should be allowed in container queries, evaluating against the container element, but then the size query container may fall back to the viewport which is not an element.
lilles commentedon Mar 14, 2025
@tabatkins @emilio @nt1m Any opinions on whether tree-counting functions like sibling-index() should be valid parse time in:
@pageproperties@font-faceand other at-rules which do not apply directly to elements@containerqueries (this is particularly interesting since the container element can be a natural choice most of the time)@mediaqueriesAnd if such functions are valid, what should they evaluate to.
Disallow tree-counting functions in non-element contexts
Disallow tree-counting functions in non-element contexts
Disallow tree-counting functions in non-element contexts
emilio commentedon Mar 14, 2025
I think it makes sense to disallow them to begin with...
Only container queries really have something resembling a sensible behavior IMO, and what should the fallback behavior be is not particularly clear...
Disallowing it gives us more leeway to decide on what the right behavior should be once there are concrete use cases for it...
tabatkins commentedon Mar 14, 2025
Yeah, I'm fine with starting with them all disallowed, parse-time invalid. We can turn them on as requested.
Bug 1954083 [wpt PR 51353] - Disallow tree-counting functions in non-…
Add sibling-index/count() tests for @font-feature-values parsing
Add sibling-index/count() tests for @font-feature-values parsing
31 remaining items
Disallow random() in style() queries
Disallow random() in style() queries
Disallow random() in style() queries
Bug 2019239 [wpt PR 58036] - Disallow random() in at-rule descriptors…
Bug 2019733 [wpt PR 58078] - Disallow random() in style() queries, a=…
Disallow random() inside @media
[css-values-5 random-item()] random-item() should be disallowed in @c…
[css-values-5] Support tree counting functions in container queries
[css-values-5] Support tree counting functions in container queries
kbhomes commentedon Sep 6, 2026
I wanted to revisit this issue for
random()now that Chrome is shipping their implementation and I'm starting work on Firefox's. The (tentative) WPTs that currently exist forrandom()(and the behavior that Chrome is shipping) indicate that it's only usable in contexts with both an element and a property name, even if the value used neitherelement-scopednorproperty-scoped/property-index-scoped. See: random-in-container-query.tentative.html, random-in-media.tentative.html, and other changes in commits associated with this issue.If I think of
random()as a normal math function that simplifies when all information is known for computation, then it seems to me that it should be allowed to parse and compute depending on the<random-key>components:fixed <number>and<dashed-ident>in all contexts:initial-valuein@property(if you consider this random key as "computationally independent", which seems right to me).element-scopedin element contexts:initial-valuein@property.property-scopedandproperty-index-scopedin property declarations only:initial-valuein@property, because even though the registered property's name could reasonably be selected as the random function's property name, this would not strictly be "computationally independent" since it uses something other than "the value of the property on the element". I can imagine authors wanting to set a random starting value for a custom property, but they would be able to use a<dashed-ident>for this purpose under this proposal.ua-*... not sure. Could be all contexts because it is its own value (like<dashed-ident>), or could be property declarations only because it's meant for that purpose?Bug 2018652 [wpt PR 57980] - Disallow random() inside @media, a=testonly
Bug 2019043 [wpt PR 58017] - Disallow random() inside @container size…
Bug 2019239 [wpt PR 58036] - Disallow random() in at-rule descriptors…
Bug 2019733 [wpt PR 58078] - Disallow random() in style() queries, a=…