- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Mar 2024 00:29: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: Make semicolons an optional upgrade to commas in CSS functions.`
<details><summary>The full IRC log of that discussion</summary>
<fantasai> -> https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1918019555<br>
<fantasai> scribe+<br>
<fantasai> TabAtkins: General problem is, we have several function in-flight which can take argument values that are the full set of CSS value syntax including comma-separated lists.<br>
<fantasai> TabAtkins: example might be var(), which isn't a problem because we intentionally put fallback as the last part, so you can know whether the commas are top-level or part of the argument<br>
<fantasai> TabAtkins: but for several other new things, that's not possible<br>
<fantasai> TabAtkins: Right now the proposals for these, when your function could contain commas, we switch to using semicolons to separate arguments in those functions.<br>
<fantasai> TabAtkins: but it does mean that during design phase of a function, we have to decide whether to use commas or semicolons<br>
<fantasai> TabAtkins: it's also a bit weird to have two distinct syntaxes, especially when most uses of these functions won't need semicolons -- most of the time will not contain commas as part of the arguement, just a keyword or whatever<br>
<fantasai> TabAtkins: So using semicolon for these when 99.9% of cases don't need it is odd<br>
<fantasai> TabAtkins: We came up with several options<br>
<fantasai> TabAtkins: 1. Don't use semicolons. Instead, allow functions to have some way to wrap arguments e.g. function, brackets, etc.<br>
<fantasai> TabAtkins: For example, 'item()' which just wraps its contents and means its contents.<br>
<fantasai> TabAtkins: we could use backets, like Grid already does<br>
<fantasai> TabAtkins: or curly braces, which aren't allowed top-level but can use inside a function<br>
<astearns> q+<br>
<fantasai> TabAtkins: Alternatively, could make the semicolons an optional upgrade<br>
<fantasai> TabAtkins: That is, you start parsing assuming comma separation<br>
<fantasai> TabAtkins: but if you hit a semicolon, reparse the function as requiring semicolons between arguments and treating commas as part of the arguments<br>
<florian> q+<br>
<fantasai> TabAtkins: I am mildly inclined to go with option 2, where semicolons are an optional upgrade<br>
<fantasai> TabAtkins: can be done across all of CSS, so don't have to think about which functions<br>
<fantasai> TabAtkins: Doesn't require extra level of nesting which we try to minimize<br>
<fantasai> TabAtkins: that said, I'm OK with any of these options<br>
<fantasai> TabAtkins: Opinions?<br>
<Rossen_> q?<br>
<oriol> q+<br>
<Rossen_> ack astearns<br>
<fantasai> astearns: Lea has asked a few times, instead of generic function, why not bare parentheses?<br>
<florian> q-<br>
<fantasai> TabAtkins: I responded -- previously purposely avoided bare parens. We used them originally e.g. for grid names, but switched away, because that would mess up SASS.<br>
<fantasai> TabAtkins: those arguments still apply<br>
<fantasai> astearns: I have a slight preference for option 1 with short function name<br>
<fantasai> astearns: I also think square brackets would be fine<br>
<fantasai> oriol: Personally I'm fine with current situation of just using semicolons.<br>
<florian> [removed myself from the queue because I wanted to ask and say the same thing as astearns]<br>
<fantasai> oriol: It's true that we need to think about it at the beginning of the function design, but it's ok to me<br>
<Rossen_> ack oriol<br>
<fantasai> oriol: I'm also OK with option 2<br>
<fantasai> oriol: among the others, they seem strange<br>
<fantasai> oriol: I would be OK with parens, but the others seem a bit strange to me<br>
<fantasai> oriol: Also argument about SASS, I wonder if there would be a possibility for them to wrap... This is a 3rd party tool, we shouldn't constrain CSS development to match outside tooling.<br>
<TabAtkins> fantasai: like Oriol, I'm fine with current situation of desinging it form the beginning. also fine with option 2. i could live with braces, but I think the function option reads as if it's part of CSS rather than an escaping mechanism.<br>
<TabAtkins> fantasai: so i'd prefer avoiding using a function.<br>
<TabAtkins> fantasai: For brackets, we already use that in other parts of CSS (Grid) so it's potentially confusing there.<br>
<TabAtkins> fantasai: But we'd *never* use braces in that same way, so we won't have the same problem<br>
<TabAtkins> fantasai: So mild pref for semicolon; their identity is a stronger comma and it's fitting we use it for that purpose<br>
<Rossen_> ack fantasai<br>
<fantasai> Rossen_: Other opinions?<br>
<fantasai> TabAtkins: Straw poll?<br>
<TabAtkins> 1. No change (design functions to use ; when it's needed)<br>
<TabAtkins> 2: use [] wrapper.<br>
<TabAtkins> 3: use {} wrapper.<br>
<TabAtkins> 4. use function wrapper (item() or similar)<br>
<TabAtkins> 5. Upgradeable semicolon (comma in general, but authors can choose to use ; instead when necessary)<br>
<TabAtkins> 5, 3<br>
<astearns> 4, 2<br>
<vmpstr> 4, 2/3<br>
<fantasai> 1, 5, 3<br>
<oriol> 1, 5<br>
<schenney> 2,4,1<br>
<miriam> 5,3,1<br>
<flackr> 5, 4<br>
<florian> 3,5<br>
<kbabbitt> 2/3, 4, 1<br>
<iank_> 5, 1 maybe<br>
<Rossen_> 4,3<br>
<fantasai> astearns: Tab you had a worry that {} might break parsing, is that still a concern?<br>
<fantasai> TabAtkins: for naive (regex) parsing yeah, but all good tools should have a real parser<br>
<TabAtkins> fantasai: If you can't do bracket matching your tool is already gonna break everywhere, so minimum you need to bea ble to bracket match<br>
<dholbert> (abstain)<br>
<schenney> 5 is also most popular 2nd option, I think<br>
<flackr> q+<br>
<fantasai> Total counts: 5.5 for 1, 2 for 2, 7 for 3, 6 for 4, 7 for 5<br>
<Rossen_> ack flackr<br>
<fantasai> flackr: Is there a problem with nesting the functions?<br>
<fantasai> TabAtkins: that's fine, because the function itself will be the wrapper<br>
<fantasai> ^Rossen: More first-place votes for option 5<br>
<florian> WFM<br>
<fantasai> Rossen_: Let's resolve on 5.<br>
<florian> +1<br>
<fantasai> TabAtkins: Was close, but 5 ekes out, and if any strong objections can re-discuss<br>
<fantasai> Rossen_: any objections to #5?<br>
<fantasai> RESOLVED: Make semicolons an optional upgrade to commas in CSS functions.<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-1982118477 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 7 March 2024 00:29:20 UTC