- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 26 Sep 2024 17:02:19 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-values-5][various] Better handling of arguments with commas`, and agreed to the following:
* `RESOLVED: Undo previous decision and move forward with optional curly-brace wrapping of complex arguments`
<details><summary>The full IRC log of that discussion</summary>
<emeyer> TabAtkins: We discussed how to deal with argument values that might have commas in them<br>
<emeyer> …We did a straw poll that ended in a tie, and did a runoff<br>
<emeyer> …That resulted in upgradeable commas, where you can replace commas as semicolons<br>
<emeyer> …This works, but upon more thought, we would like revisit this decision and go with the other thing that got first place<br>
<emeyer> …The option we want to go with instead is to use a curly brace wrapper around the values<br>
<emeyer> …So if you write an if with a comma-separated condition, you write it like this (shows syntax from comment on issue)<br>
<emeyer> …So it can either be a single curly brace block containing anything that’s valid, or it’s a sequence of component values<br>
<emeyer> …This way as long as you’re doing anything fancy, you can just write the fuction exactly as you would elsewhere<br>
<emeyer> …An argument with commas gets marked as being a special thing<br>
<emeyer> …In the original version, you use quoted strings separated by commas<br>
<emeyer> …YOu can end up with one thing being valid and one not valid, and you can only fix it with a trailing comma<br>
<emeyer> …This is bad<br>
<emeyer> s/YOu/You/<br>
<emeyer> …It looks bad and it’s inconsistent with other things<br>
<emeyer> …The curly braces make it clear where the complicated bits start and stop<br>
<emeyer> …This also makes other issues easier<br>
<emeyer> …There are a few parsing questions about how this would apply to var()<br>
<emeyer> …They’re arcane<br>
<oriol> q+<br>
<emeyer> …So we’d like to change to curly brace wrapping and resolve on that instead<br>
<astearns> ack oriol<br>
<emeyer> oriol: I agree the commas were not a great decision, but I have a mild preference for the original idea to require semicolons<br>
<emeyer> …It avoids authors thinking if they use a var(), maybe the value is something typical<br>
<emeyer> …But the semicolons has some downsides so I’m okay with doing this<br>
<emeyer> TabAtkins: Oriol’s pointing out authors had to memorize the special-casde syntax even if they didn’t often use it<br>
<emeyer> …This is what turned us against it; we wanted something lower-touch<br>
<emeyer> TabAtkins: (shows an example of the older syntax)<br>
<emeyer> s/casde/case/<br>
<lea> q?<br>
<emeyer> TabAtkins: This would have required defensive coding, but that’s kind of true of any syntax we decide to use<br>
<emeyer> …The only one that avoids it is “always use semicolons” but we rejected that for other reasons<br>
<lea> q+ to say agree that a wrapping construct is better than upgradable commas. The natural option here is bare parens, and I don't buy the argument that we should contort our syntax *forever* to accommodate a preprocessor, especially now that its popularity is dwindling<br>
<astearns> ack lea<br>
<Zakim> lea, you wanted to say agree that a wrapping construct is better than upgradable commas. The natural option here is bare parens, and I don't buy the argument that we should contort<br>
<Zakim> ... our syntax *forever* to accommodate a preprocessor, especially now that its popularity is dwindling<br>
<emeyer> lea: I agree that upgradable commas are weird and wrapping constructs are much better<br>
<emeyer> …For the best wrapping construct would be, we can discuss options but I agree that bare parentheses are the natural option<br>
<emeyer> …We should not contort CSS syntax forever<br>
<emeyer> …The choice to prioritize Sass syntax over natural syntax seems weird<br>
<emeyer> TabAtkins: We used quare brackets in Grid because it was easier at the time<br>
<emeyer> …Here, bare parentheses were proposed and it was pointed out we’d decided against that in the past and didn’t want to revisit that<br>
<kizu> q+<br>
<miriam> q+<br>
<emeyer> …I don’t think there’s an overriding reason to go back and revisit our decision to avoid those<br>
<astearns> ack kizu<br>
<emeyer> kizu: +1 to Lea<br>
<emeyer> …I think plain parentheses would be better<br>
<emeyer> …Curly braces mean a block in CSS<br>
<dbaron> (I agree that wrapping is better than trailing semicolons as a defensive technique, for what it's worth.)<br>
<lea> bare parens are the quintessential grouping construct. No braces, brackets, or function compares to the natural ergonomics of bare parens for this. IMO<br>
<emeyer> (scribe having trouble making out what’s being said)<br>
<emeyer> …I do want to use commas with braces<br>
<astearns> ack miriam<br>
<emeyer> miriam: I think the same can be said the other way about parentheses in CSS< which are only used on function and calculations<br>
<lea> q?<br>
<emeyer> …This stands out as being different and looking different<br>
<astearns> ack fantasai<br>
<lea> q+ to say in every prog lang parens are used for functions and grouping, this is not new<br>
<emeyer> fantasai: The advantage of curly braces is it leaves parentheses to be used for something more useful than “we needed to escape commas here”<br>
<tantek> +1 dbaron, lea<br>
<emeyer> …I don’t think we should take a syntax that could be much more useful here<br>
<ntim> `toggle(« Arial, Helvetica, sans-serif », « Times, serif »)` :D<br>
<emeyer> lea: I don’t see it as escaping, I see it as grouping<br>
<emeyer> …In every popular language, parentheses are used for grouping<br>
<emeyer> …We do that inside our own calc()<br>
<emeyer> …If we end up deciding other constructs are better, regardless of the Sass problem, there’s no Sass problem in the first place<br>
<astearns> q?<br>
<astearns> ack lea<br>
<Zakim> lea, you wanted to say in every prog lang parens are used for functions and grouping, this is not new<br>
<emeyer> TabAtkins: Because the reasons for the original Sass allowances are valid and are even more so here, Chrome would object to using parentheses for this case regardless<br>
<emeyer> q?<br>
<emeyer> astearns: We have two options, each with champions, and one has an objection<br>
<emeyer> …Is there anyone who would object to curly braces<br>
<emeyer> lea: There are other options like square brackets<br>
<emeyer> fantasai: Square brackets aren’t an option because you’d have to escape them<br>
<emeyer> TabAtkins: You wouldn’t but other options lost to curly braces<br>
<emeyer> …in the original poll<br>
<fantasai> s/escape them/escape them in grid/<br>
<TabAtkins> TabAtkins: Chrome doesn't object to the other options, but {} won the original poll<br>
<romain> Curly brackets look quite nice in this example by kizu for inline conditions : https://github.com/w3c/csswg-drafts/issues/10064#issuecomment-2373483709<br>
<lea> Option 1: Bare ()<br>
<lea> Option 2: {}<br>
<lea> Option 3: []<br>
<lea> Option 4: Function e.g. value(), val(), arg(), item()<br>
<emeyer> astearns: It’s not clear to me that the options for parentheses transfeer to square brackets<br>
<emeyer> …It’s another grouping mechanism<br>
<ntim> 2<br>
<fantasai> 2<br>
<romain> 2<br>
<kbabbitt> 2<br>
<lea> 3<br>
<emeyer> s/transfeer/transfer/<br>
<ethanjv> 2<br>
<moonira> 2<br>
<chrishtr> 2<br>
<alisonmaher> 2<br>
<kizu> 4<br>
<emeyer> …Looks like we’re doing a straw poll; Lea put options into IRC<br>
<miriam> 2<br>
<TabAtkins> 2<br>
<keithamus> 2/3<br>
<Penny> 2<br>
<emeyer> …Please put in a number corresponding to your preference<br>
<astearns> 2<br>
<futhark> 4<br>
<lea> actually 3/4 for me<br>
<dbaron> 2<br>
<vmpstr> abstain<br>
<rachelandrew> 2<br>
<dholbert> abstain<br>
<ydaniv> abstain<br>
<emeyer> abstain<br>
<castastrophe> 2<br>
<masonf> abstain<br>
<emeyer> astearns: Poll looks pretty clear toward curly brackets<br>
<oriol> Preference for requiring semicolons. But 2 among the above.<br>
<emeyer> …Is there anyone who would object to that option?<br>
<emeyer> (silence)<br>
<emeyer> …Given the straw poll, I suggest we resolve on using curly braces<br>
<emeyer> …Objections?<br>
<emeyer> astearns: Hearing none, we will undo the previous resolution<br>
<emeyer> RESOLVED: Undo previous decision and move forward with optional curly-brace wrapping of complex arguments<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-2377487819 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:02:20 UTC