- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 21 May 2025 16:33:06 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <fantasai> futhark: Some functions are only possible in some contexts, e.g. property declarations or other places where we have an element context<br> <fantasai> futhark: descriptors, media queries, etc. don't have element context<br> <fantasai> futhark: For font-relative units we fall back to the default font, but no such fallback for sibling-index()<br> <fantasai> futhark: Conclusion is to drop such functions at parse-time as invalid where they don't make sense<br> <weinig> q+<br> <fantasai> futhark: we can add back case-by-case if something makes sense<br> <emilio> q+<br> <fantasai> futhark: One question is wrt container queries, which does have an element context: should we allow such functions in container values?<br> <Rossen8> ack weinig<br> <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<br> <fantasai> weinig: Quite a matrix now, that each function needs to think about<br> <fantasai> weinig: like properties, standard set of questions to answer, would be helpful<br> <Rossen8> ack emilio<br> <TabAtkins> +1 to finding the set of constraints that we should formalize around<br> <fantasai> emilio: Agree this is an issue, and container queries is interesting<br> <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<br> <fantasai> emilio: So my preference would be to start by disallowing, and if people ask for it, we can enable later<br> <fantasai> emilio: but also ok if people think it's useful to hvae<br> <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<br> <emilio> q+<br> <fantasai> futhark: if it's a registered query<br> <Rossen8> ack emilio<br> <miriam> q+<br> <fantasai> emilio: I was thinking about container queries like size container queries and such<br> <fantasai> futhark: That too. But wrt style queries specifically<br> <fantasai> emilio: For style queries... I am not sure I follow, can't you just disallow those functions while parsing?<br> <fantasai> emilio: That maybe presumes those functions wouldn't be part of the syntax<br> <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()<br> <fantasai> miriam: If we disallow any of these, we should consider one at a time in container queries<br> <fantasai> miriam: I do think there might be use cases, so I wouldn't want to take as a group<br> <Rossen8> ack miriam<br> <fantasai> miriam: because here they would have a meaning, so we'd disallow for some other reason<br> <weinig> q+<br> <Rossen8> ack weinig<br> <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<br> <fantasai> weinig: For instance, if relative units aren't allowed, but you're using <<number>> a calc() with relative uits wouldn't be allowed<br> <fantasai> weinig: It's both these unique contexts, and these unique values, that have certain dependencies<br> <fantasai> weinig: Probably you want one or the other, but maybe both?<br> <fantasai> weinig: But need to figure out what the constraints are, to define that matrix<br> <fantasai> futhark: I'm fine with starting by disallowing these functions in contexts where you don't have an element<br> <weinig> q+<br> <fantasai> futhark: If I understood you , Mia, you're fine with not supporting anything and then bringing in each function that has a need?<br> <fantasai> miriam: Is there a good reason to start that way?<br> <fantasai> miriam: I think there are going to be use case for these, and we do have a context for them<br> <fantasai> miriam: so want to know if there are particular reasons not to support them<br> <emilio> q+<br> <fantasai> futhark: I've been working with sibling-index() and sibling-count(), we have an implementation, haven't found any problems<br> <Rossen8> ack weinig<br> <fantasai> weinig: I think just going and disallowing in some context is too simplistic<br> <fantasai> weinig: disallowing wholeheartedly, would disallow calc() with certain values<br> <fantasai> weinig: It's a more complicated question, which elements in which contexts<br> <TabAtkins> Yeah, math functions don't bring any context requirements *themselves*, just their contents<br> <fantasai> futhark: would it make sense to start with tree-counting functions, separately?<br> <fantasai> futhark: or would that be too wide<br> <fantasai> weinig: It's a problem to do one-off restrictions, rather than figuring out the system<br> <fantasai> weinig: We'd have to look at the whole landscape again<br> <fantasai> weinig: so now is the time to define these characteristics<br> <fantasai> futhark: Can we get a resolution on container queries to explicitly allow tree-counting functions for now?<br> <fantasai> weinig: sounds reasonable to me<br> <fantasai> weinig: we think CQ will have an element context, so seems reasonable to allow them now, and formalize more later<br> <fantasai> futhark: So we can extend the CQ spec, which currently talks about font-relative units. We can expand to include tree-counting functions<br> <miriam> +1<br> <fantasai> futhark: Then let's resolve that now, and continue the rest of the discussion<br> <Rossen8> ack emilio<br> <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 ....<br> <fantasai> emilio: Right now :has() has this problem, too, needs to invalidate deeper to invalidate random elements in arbitrary parts of the tree<br> <fantasai> emilio: The usual stuff doesn't have this complexity<br> <fantasai> emilio: it's a lot more non-local than using it in property declarations<br> <fantasai> emilio: That said, it *can* be implemented, so I'm fine allowing it<br> <fantasai> futhark: similar issue with keyframe animations<br> <fantasai> futhark: so multiple cases of it<br> <fantasai> fantasai: If there are use cases, then it's worth doing the extra work; if not, it's not worth doing<br> <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<br> <fantasai> Rossen8: So this is an academic expectation rather than a practical one<br> <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<br> <fantasai> miriam: Things can resolve because we have a container to resolve against<br> <fantasai> futhark: Proposed to explicitly allow tree-counting functions in CQ<br> <fantasai> PROPOSED: Explicitly allow tree-counting functions in container queries<br> <fantasai> Rossen8: any additional points or objections?<br> <fantasai> RESOLVED: Explicitly allow tree-counting functions in container queries<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10982#issuecomment-2898572289 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 21 May 2025 16:33:07 UTC