[css-values-5] Disallow mix/random/tree-counting functions in some contexts

[cdoublev]

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.

[fantasai]

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]

Allowing them anywhere would require making some arguments (<'animation-timeline'>, per-element) invalid in these other contexts.

[lilles]

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]

@tabatkins @emilio @nt1m Any opinions on whether tree-counting functions like sibling-index() should be valid parse time in:

• @page properties
• descriptors for @font-face and other at-rules which do not apply directly to elements
• @container queries (this is particularly interesting since the container element can be a natural choice most of the time)
• @media queries

And if such functions are valid, what should they evaluate to.

[emilio]

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]

Yeah, I'm fine with starting with them all disallowed, parse-time invalid. We can turn them on as requested.

[lilles]

Only container queries really have something resembling a sensible behavior IMO, and what should the fallback behavior be is not particularly clear...

Container queries should always be in an element context, right?

css-conditional-5 currently says:

"Relative length units (including container query length units) and custom properties in container query conditions are evaluated based on the computed values of the query container."

which could be extended to include evaluation of tree counting functions based on the container element.

[emilio]

Yes, that's the "something resembling a sensible behavior" :)

[css-meeting-bot]

The CSS Working Group just discussed [css-values-5] Disallow mix/random/tree-counting functions in some contexts, and agreed to the following:

• RESOLVED: Explicitly allow tree-counting functions in container queries

The full IRC log of that discussion

<fantasai> futhark: Some functions are only possible in some contexts, e.g. property declarations or other places where we have an element context
<fantasai> futhark: descriptors, media queries, etc. don't have element context
<fantasai> futhark: For font-relative units we fall back to the default font, but no such fallback for sibling-index()
<fantasai> futhark: Conclusion is to drop such functions at parse-time as invalid where they don't make sense
<weinig> q+
<fantasai> futhark: we can add back case-by-case if something makes sense
<emilio> q+
<fantasai> futhark: One question is wrt container queries, which does have an element context: should we allow such functions in container values?
<Rossen8> ack weinig
<fantasai> weinig: These issues speak to a need, when defining CSS functions, to have a table that specifies how they operate and what contexts they're allowed in
<fantasai> weinig: Quite a matrix now, that each function needs to think about
<fantasai> weinig: like properties, standard set of questions to answer, would be helpful
<Rossen8> ack emilio
<TabAtkins> +1 to finding the set of constraints that we should formalize around
<fantasai> emilio: Agree this is an issue, and container queries is interesting
<fantasai> emilio: I suspect it might be annoying to invalidate on container queries, and I can't think of a good use case... not that ppl might not come up with one
<fantasai> emilio: So my preference would be to start by disallowing, and if people ask for it, we can enable later
<fantasai> emilio: but also ok if people think it's useful to hvae
<fantasai> futhark: For style queries, we currently parse as a non-registered property, so we don't know until we're finished parsing that it's not a property
<emilio> q+
<fantasai> futhark: if it's a registered query
<Rossen8> ack emilio
<miriam> q+
<fantasai> emilio: I was thinking about container queries like size container queries and such
<fantasai> futhark: That too. But wrt style queries specifically
<fantasai> emilio: For style queries... I am not sure I follow, can't you just disallow those functions while parsing?
<fantasai> emilio: That maybe presumes those functions wouldn't be part of the syntax
<fantasai> futhark: When you parse the property the first time, you don't have a registered property on the first pass. So you don't know if it's a sibling-index()
<fantasai> miriam: If we disallow any of these, we should consider one at a time in container queries
<fantasai> miriam: I do think there might be use cases, so I wouldn't want to take as a group
<Rossen8> ack miriam
<fantasai> miriam: because here they would have a meaning, so we'd disallow for some other reason
<weinig> q+
<Rossen8> ack weinig
<fantasai> weinig: Another way to think of this is to reverse it, and say, for each context where CSS values can be used, we should define what types of CSS values are allowed
<fantasai> weinig: For instance, if relative units aren't allowed, but you're using <<number>> a calc() with relative uits wouldn't be allowed
<fantasai> weinig: It's both these unique contexts, and these unique values, that have certain dependencies
<fantasai> weinig: Probably you want one or the other, but maybe both?
<fantasai> weinig: But need to figure out what the constraints are, to define that matrix
<fantasai> futhark: I'm fine with starting by disallowing these functions in contexts where you don't have an element
<weinig> q+
<fantasai> futhark: If I understood you , Mia, you're fine with not supporting anything and then bringing in each function that has a need?
<fantasai> miriam: Is there a good reason to start that way?
<fantasai> miriam: I think there are going to be use case for these, and we do have a context for them
<fantasai> miriam: so want to know if there are particular reasons not to support them
<emilio> q+
<fantasai> futhark: I've been working with sibling-index() and sibling-count(), we have an implementation, haven't found any problems
<Rossen8> ack weinig
<fantasai> weinig: I think just going and disallowing in some context is too simplistic
<fantasai> weinig: disallowing wholeheartedly, would disallow calc() with certain values
<fantasai> weinig: It's a more complicated question, which elements in which contexts
<TabAtkins> Yeah, math functions don't bring any context requirements *themselves*, just their contents
<fantasai> futhark: would it make sense to start with tree-counting functions, separately?
<fantasai> futhark: or would that be too wide
<fantasai> weinig: It's a problem to do one-off restrictions, rather than figuring out the system
<fantasai> weinig: We'd have to look at the whole landscape again
<fantasai> weinig: so now is the time to define these characteristics
<fantasai> futhark: Can we get a resolution on container queries to explicitly allow tree-counting functions for now?
<fantasai> weinig: sounds reasonable to me
<fantasai> weinig: we think CQ will have an element context, so seems reasonable to allow them now, and formalize more later
<fantasai> futhark: So we can extend the CQ spec, which currently talks about font-relative units. We can expand to include tree-counting functions
<miriam> +1
<fantasai> futhark: Then let's resolve that now, and continue the rest of the discussion
<Rossen8> ack emilio
<fantasai> emilio: I just wanted to note, regarding complexity, the one that's annoying is inserting an element in the DOM, assuming index of container ....
<fantasai> emilio: Right now :has() has this problem, too, needs to invalidate deeper to invalidate random elements in arbitrary parts of the tree
<fantasai> emilio: The usual stuff doesn't have this complexity
<fantasai> emilio: it's a lot more non-local than using it in property declarations
<fantasai> emilio: That said, it *can* be implemented, so I'm fine allowing it
<fantasai> futhark: similar issue with keyframe animations
<fantasai> futhark: so multiple cases of it
<fantasai> fantasai: If there are use cases, then it's worth doing the extra work; if not, it's not worth doing
<fantasai> futhark: I would expect there to be use cases for style queries in particular, because computed style can use sibling-index() so it would be natural to allow
<fantasai> Rossen8: So this is an academic expectation rather than a practical one
<fantasai> miriam: I'm trying to encourage expectation that things in CQ resolve based on the container, and the more that's true the easier that is to teach
<fantasai> miriam: Things can resolve because we have a container to resolve against
<fantasai> futhark: Proposed to explicitly allow tree-counting functions in CQ
<fantasai> PROPOSED: Explicitly allow tree-counting functions in container queries
<fantasai> Rossen8: any additional points or objections?
<fantasai> RESOLVED: Explicitly allow tree-counting functions in container queries

[lilles]

wpt tests:

https://wpt.fyi/css/css-values/tree-counting/sibling-function-container-query.html
https://wpt.fyi/css/css-values/tree-counting/sibling-function-container-query-invalidation.html