- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Apr 2025 20:12:53 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-values-5] if() conditions with calc() comparisons`, and agreed to the following: * `RESOLVED: Add numerical comparisons wrapped in bare parens, use 3-value logic for incomparable comparisons` <details><summary>The full IRC log of that discussion</summary> <fantasai> TabAtkins: if() function lets you specify several types of test. MQ, CQ, supports Q<br> <fantasai> TabAtkins: style Q<br> <fantasai> TabAtkins: Would be useful to be able to do generic numeric comparisons, so e.g. could do var and number<br> <fantasai> TabAtkins: You can currently do that by style query, but would be nice ot be able to inline the value<br> <fantasai> TabAtkins: so suggest to allow simple numeric comparisons. Comparison operator in the middle. Just like MQ.<br> <fantasai> TabAtkins: question about how to spell it<br> <miriam> we haven't resolved on range comparisons for style queries, it's on the agenda<br> <fantasai> TabAtkins: Suggest to use naked parens<br> <lea> q+<br> <TabAtkins> flex-flow: if( (100vw > 200px): row ; else : column; );<br> <fantasai> TabAtkins: could come up with a name for this test, make it a function if ppl object to bare parens / have a good function name<br> <astearns> ack lea<br> <oriol> q+<br> <fantasai> lea: We control the grammar.. couldn't we just put inline?<br> <fantasai> TabAtkins: it's ambiguous because we allow boolean operators<br> <fantasai> lea: If you don't use boolean operators, could we drop parens?<br> <fantasai> TabAtkins: You do need brackets even then, to handle future expansion.<br> <fantasai> TabAtkins: if you put anything unknown, e.g. new unit, you don't want to invalidate the entire declaration<br> <fantasai> TabAtkins: you want to catch it by the general-enclosed production<br> <fantasai> TabAtkins: That way "x or y" if x is new syntax, it's false, and y is true, test passes<br> <fantasai> lea: Could we define [missed]<br> <fantasai> TabAtkins: not in general case, because you don't know the bounds of an arbitrary new syntax<br> <fantasai> TabAtkins: we're ok with defining ourselves into matched brackets, but without explicit boundary it imposes too much grammatical ambiguity<br> <fantasai> lea: any cases where it wouldn't be ambiguous?<br> <fantasai> lea: e.g. dimension cmp dimension. Or replace one of those with a var. These are the most common cases.<br> <fantasai> lea: I would argue that over 90% of use cases will fall into that category<br> <fantasai> TabAtkins: I don't want to try and burden us with the fact that all future CSS value design in all contexts has to live under this restriction due to if()<br> <fantasai> lea: I'm suggesting to have the parens for most cases, but carve out a subset of cases that don't require it<br> <fantasai> TabAtkins: that still runs us into future ambiguity problems. E.g. can't use ':' because that's delimeter<br> <fantasai> astearns: not necessarily. lea's saying that we can possibly drop parens for a subset of thing, but require them in other situations<br> <fantasai> astearns: so that would require parens<br> <astearns> ack oriol<br> <fantasai> TabAtkins: Would need to learn weirdness of our parsing limitations. Try to avoid that when possible<br> <dbaron> (I think it might also require 2-pass parsing.)<br> <fantasai> oriol: Some values are resolved at used value, not computed value, e.g. length vs percentage.<br> <fantasai> oriol: that would always resolve as false<br> <TabAtkins> width: if( (100% > 200px): max-content; else : stretch; );<br> <fantasai> TabAtkins: in this example, the percent depends on available space which is not known until layout time<br> <fantasai> TabAtkins: but needs to replace for computed value<br> <fantasai> TabAtkins: at the moment, I think only thing we can do is treat this comparison as false, because can't resolve at computed value time<br> <fantasai> TabAtkins: alternative would be to also define a calc() conditional thing, and have it resolve into that calc() expression<br> <fantasai> TabAtkins: but that would be a lot of extra complexity for this case<br> <lea> q+<br> <fantasai> TabAtkins: I think this is a not-great situation no matter what we do<br> <fantasai> TabAtkins: so current idea is to just call it false<br> <astearns> ack lea<br> <fantasai> lea: Right now there are ways to use min()/max()/clamp() for this<br> <fantasai> lea: seems weird if doesn't have same machinery<br> <fantasai> TabAtkins: yes, but we're mixing 2 different classes of functions. This is arbitrary substitution function, can do anything, but has to be fully resolved before inheritane.<br> <fantasai> TabAtkins: we cannot inherit an unresolved substitution function<br> <fantasai> TabAtkins: e.g. var() has to be resolved by computed value time. This is the same thing.<br> <lea> q?<br> <TabAtkins> fantasai: instead of making those always false, can we state them as always invalid? same effect but then CSS devtools can flag them as wrong?<br> <lea> q+ or possibly have an unknown state<br> <lea> q+<br> <TabAtkins> fantasai: then authors won't be as confused<br> <fantasai> TabAtkins: sure, we can have devtools flag that as a problem<br> <astearns> ack lea<br> <fantasai> lea: If we must have that sort of thing, it doesn't seem right to evaluate as false. What if we had an unknown state?<br> <fantasai> TabAtkins: We do have 3-value algebra in MQ, so ...<br> <fantasai> lea: So would want to style it differently.<br> <kizu> `catch: `<br> <fantasai> TabAtkins: you don't want the test to be false, but not-test to be true, 3-value logic we have handles that<br> <fantasai> TabAtkins: so yes, makes sense<br> <fantasai> TabAtkins: So treat these as unknown, yes<br> <fantasai> fantasai: so like I said, invalid / uknown<br> <fantasai> astearns: So should we resolve to adopt the wrapped-in-parens version of this with 3-value logic?<br> <fantasai> PROPOSED: Add numerical comparisons wrapped in bare parens, use 3-value logic for incomparable comparisons<br> <fantasai> astearns: People can open separate issues for refinements<br> <fantasai> astearns: e.g. for dropping parens in some cases, or evaluating different timing<br> <fantasai> astearns: any more comments or concerns?<br> <fantasai> RESOLVED: Add numerical comparisons wrapped in bare parens, use 3-value logic for incomparable comparisons<br> <dbaron> (I'm also a bit hesitant about the bare parens syntax...)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11104#issuecomment-2770574546 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 1 April 2025 20:12:54 UTC