- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 26 Sep 2024 17:35:17 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-values-5] What is the MVP for inline conditionals on custom properties?`, and agreed to the following: * `RESOLVED: We will use if(cond(): foo; else: bar)` * ``RESOLVED: If you have an else clause, you must say `else` explicitly`` <details><summary>The full IRC log of that discussion</summary> <emeyer> lea: In June, we resolving to work on inline conditionals<br> <emeyer> …There were syntax disagreements, but we seem to be converging on a specific option<br> <lea> https://github.com/w3c/csswg-drafts/issues/10064#issuecomment-2372578597<br> <emeyer> …There were disagreements about else being optional or mandatory<br> <emeyer> …How does it resolve, what should separators be<br> <emeyer> …Converging on an else clause that it spelled out<br> <emeyer> …If the else is omitted and nothing matches, it decomposes to a token stream<br> <emeyer> …Right now, we need a resolution for that and for waht the separator should be<br> <emeyer> …We think there’s value in having a different separator for the condition and the values<br> <kbabbitt> q+<br> <emeyer> …Tab suggests colons, I suggest question marks<br> <kizu> q+<br> <emeyer> kbabbitt: I think as written, it allows multiple elses<br> <emeyer> …There’s also a proposal in the thread to drop separators and I like it, I think it looks cleaner<br> <emeyer> TabAtkins: This does allow an else to be put anywhere; it’s sometimes useful when debugging<br> <astearns> ack kbabbitt<br> <emeyer> …I think it’s valuable to have the ability to do that<br> <lea> essentially else is just another way to say true, right?<br> <fantasai> the only way? :)<br> <emeyer> …For Roman’s proposal, he’s using curly braces, which aren’t required<br> <lea> we should have true and false constants for <boolean>...<br> <emeyer> …There is no grammatical reason for the separator<br> <emeyer> …They’re meant to guide the eye to separators<br> <emeyer> …Oh wait no, not true<br> <emeyer> …If you have max-width and something, it could get greedy<br> <emeyer> …So we do need something<br> <lea> not to mention in the future <decl-value> could include <boolean> too<br> <astearns> ack kizu<br> <emeyer> …to be a separator<br> <emeyer> kizu: If we’re settled on curly braces, making them necessary so we can use colon and question mark<br> <emeyer> …If choosing between colon and question mark, I would choose colon<br> <emeyer> …My proposal looks more like CSS in my opinion<br> <keithamus> q?<br> <oriol> q+<br> <emeyer> TabAtkins: We’d like a resolution on this grammar looking good with a quick poll on the separator value<br> <astearns> ack fantasai<br> <kbabbitt> q+<br> <emeyer> fantasai: Can we go through the questions you were debating?<br> <lea> https://github.com/w3c/csswg-drafts/issues/10064#issuecomment-2368914947<br> <emeyer> lea: I think we need to consider both short and long ifs<br> <fantasai> Separator between condition and values (? vs :)<br> <fantasai> Separator between value if true and value if false (; vs ,/; vs :)<br> <fantasai> Trailing separator allowed? (mainly with ; syntaxes)<br> <fantasai> Mandatory or optional else?<br> <fantasai> If optional: what happens if nothing matches? Empty token or IACVT?<br> <lea> s/I think we need to consider both short and long ifs/in considering syntax options, one should think of *both* very short conditionals (possibly with a single value consisting of many of them)/<br> <emeyer> TabAtkins: The problem with not requiring `else` when there’s an else, you could get parsing problem<br> <emeyer> …Lea and I decided it was okay to require the else because it’s unambiguous<br> <keithamus> q+<br> <emeyer> …The subissue is whether a missing fallback else leads to empty token or IACVT<br> <flackr> q+<br> <lea> lea: What is the use case for triggering IACVT intentionally? Remember if your whole value is if() you get that anyway<br> <emeyer> astearns: We should go to the queue and then try to get resolutions for remaining questions<br> <lea> lea: Whereas there are many use cases for getting an empty token stream<br> <emeyer> fantasai: I would like an explkicit resolution on each of the raised questions<br> <emeyer> astearns: If you have concerns on any of the decisions, they should be raised as separate issues<br> <emeyer> oriol: I like the proposal of using curly braces<br> <emeyer> …As I understand it, the curly braces would be required and we would comma-separate cases<br> <fantasai> -> https://github.com/w3c/csswg-drafts/issues/10064#issuecomment-2373483709<br> <emeyer> kizu: This is correct<br> <emeyer> TabAtkins: I’m uncomfortable with not separating cases<br> <fantasai> s/cases/arguments in a list of arguments with a comma/<br> <emeyer> astearns: I suggest that become a separate issue<br> <astearns> ack keithamus<br> <astearns> ack oriol<br> <astearns> ack kbabbitt<br> <emeyer> kbabbitt: I advocated for the curly braces but I like the comma syntax looking like a declaration block<br> <emeyer> …I lean toward comma between values, semicolon between blocks<br> <emeyer> …I think the else should be optional<br> <emeyer> s/optional/mandatory/<br> <lea> My position was: As long as else is optional, I don't think it's a big imposition to label it explicitly.<br> <emeyer> keithamus: The question token looks strange if else is mandatory<br> <kbabbitt> s/comma between values/colon between condition and value/<br> <emeyer> …The colon fits well with the grammar as I understand it<br> <kbabbitt> s/else should be optional/else should be mandatory/<br> <emeyer> …Empty token vs IACVT; is the token something we can reason about?<br> <emeyer> …If you have a custom property that evaluates to an empty token, you could reason about it with another custom property to provide a fallback<br> <emeyer> TabAtkins: I don’t think that works, but it depends on what conditions are allowed<br> <emeyer> keithamus: I think that should be considered<br> <emeyer> TabAtkins: I would love to see that as an issue with a simple use case<br> <astearns> ack flackr<br> <emeyer> flackr: Is there an easy way to get the value that’s in the cascade before the property?<br> <emeyer> …I can see that would be useful<br> <emeyer> TabAtkins: I suspect the answer is, whatever style queries can do<br> <emeyer> …SO I think not right now<br> <emeyer> …I don’t know how much I want to divert from other queries right now<br> <emeyer> flackr: If you didn’t specify else, and no conditions matched, we could use the value that would have been used without the custom<br> <emeyer> TabAtkins: That runs into a proposal by Lea<br> <emeyer> fantasai: Want to point out that colon and semicolon that follows an existing pattern we have a lot of<br> <kizu> +1 to `if(cond(): foo; else: bar)`, this was in my other earlier comment in the issue (require mandatory `;` as a separator, not an upgradable one)<br> <emeyer> …If we want to use commas, it probably makes more sense to use question marks<br> <lea> https://www.irccloud.com/pastebin/4Zx0VWlX/<br> <lea> Option 1: ?<br> <lea> Option 2: :<br> <ethanjv> 2<br> <vmpstr> 2<br> <emeyer> astearns: Straw polling on separators<br> <alisonmaher> 2<br> <kizu> 2<br> <TabAtkins> 2<br> <romain> 1<br> <lea> 1<br> <flackr> 2<br> <ydaniv> 2<br> <kbabbitt> 2<br> <fantasai> 1<br> <moonira> 2<br> <miriam> 2<br> <astearns> 2<br> <chrishtr> 2<br> <Penny> 2<br> <keithamus> 2<br> <jarhar> 2<br> <matthieud> abstain<br> <oriol> 2. Wouldn't mind {} either<br> <futhark> 2<br> <dholbert> abstain<br> <emeyer> abstain<br> <masonf> abstain<br> <andreubotella> abstain<br> <fantasai> I would be OK with `:` if we were using `;` as a separator, but `:` and `,` is weird.<br> <dbaron> abstain<br> <emeyer> astearns: We can decide on colon for now; are we also going to straw poll the separator?<br> <emeyer> TabAtkins: We can<br> <ydaniv> +1 for fantasai<br> <ntim> I like `:` and `,` personally<br> <emeyer> fantasai: I think commas as a separator makes sense, but pairing them with colons is weird because of the way the rest of CSS works<br> <emeyer> …So I think they should be considered as a set<br> <lea> Option 1: if(test? v1, v2)<br> <lea> Option 2: if(test: v1, v2)<br> <emeyer> …That’s what’s reading weird to me<br> <emeyer> …In isolation, any combination is fine, but in context it’s weird to invert the precedence of these<br> <kizu> +1 to fantasai<br> <futhark> +1 to fantasai<br> <emeyer> astearns: Anyone who voted 2 and is convinced by Elika’s argument?<br> <vmpstr> +1<br> <emeyer> flackr: What are the options?<br> <lea> Option 1: if(test? v1, v2)<br> <lea> Option 2: if(test: v1, v2)<br> <lea> 1<br> <TabAtkins> 1) if(cond()? foo, else? bar)<br> <TabAtkins> 2) if(cond(): foo, else: bar)<br> <TabAtkins> 3) if(cond(): foo; else: bar)<br> <kizu> 3<br> <flackr> 3<br> <futhark> 3<br> <fantasai> 1 or 3<br> <TabAtkins> 2<br> <kbabbitt> 3<br> <moonira> 3<br> <vmpstr> 3<br> <astearns> 3<br> <keithamus> 3<br> <romain> 1 or 3<br> <ydaniv> 3<br> <ethanjv> 3<br> <dbaron> 3<br> <chrishtr> 3<br> <masonf> 3<br> <emeyer> astearns: Votes are according to Tab’s options<br> <alisonmaher> 3<br> <miriam> 1 or 3 equally<br> <emilio> 2 or 3<br> <ntim> 2 > 3<br> <oriol> 2 or 3<br> <kschmi> 3<br> <emeyer> 3<br> <emeyer> astearns: The 3’s have it<br> <TabAtkins> winner: if(cond(): foo; else: bar)<br> <emeyer> …We will use colons and semicolons; any objections?<br> <emeyer> RESOLVED: We will use if(cond(): foo; else: bar)<br> <keithamus> (regarding the decision of empty vs IACTV https://github.com/w3c/csswg-drafts/issues/10956)<br> <emeyer> fantasai: We could resolve on mandatory else<br> <emeyer> TabAtkins: We have to do that<br> <emeyer> fantasai: We could resolve that if you have an else clause, you must say else explicitly<br> <emeyer> astearns: Any objections?<br> <emeyer> (silence)<br> <emeyer> RESOLVED: If you have an else clause, you must say `else` explicitly<br> <oriol> q+<br> <astearns> ack fantasai<br> <emeyer> keithamus: I don’t know which one of the two options I stated in the issue should be available syntax<br> <astearns> ack oriol<br> <lea> IACVT if nothing matches means you cannot do things like background: if(test, yellow) if(test, linear-gradient(...) top);<br> <emeyer> oriol: If we are going with semicolon separator between cases, are we requiring that inside curly braces??<br> <emeyer> fantasai: I think that’s no longer needed<br> <lea> so you sacrifice composability, but get absolutely no advantage<br> <emeyer> TabAtkins: I’m not sure if it’s a requirement now or not, I’ll have to think about it<br> <emeyer> astearns: I think we’re done with this issue for today<br> <emeyer> …Break time needed; will resume at the top of the hour<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10064#issuecomment-2377557682 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 26 September 2024 17:35:18 UTC