- 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