- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Apr 2020 16:30:52 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Allow trailing comma in gradient functions (and probably others)`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Allow trailing comma in gradient functions (and probably others)<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4968<br> <dael> Rossen___: TabAtkins or AmeliaBR ?<br> <dael> AmeliaBR: I can talk about it if no one else wants to<br> <dael> Rossen___: Are we prepared? This was added by fan<br> <dael> AmeliaBR: Some in issue discussion<br> <dael> AmeliaBR: Feature request is to support a trailing comma in comma sep lists. Example was in a gradient function where adding or removing function stops and in course you have to fuss with making sure last item doesn't have a comma. That's annoying and can make diffs on version control more confusing<br> <dael> AmeliaBR: I commented that it's not just inside gradient functions. Same irritation when editing background or text-shadow lists<br> <dael> AmeliaBR: Remove one item and comments are all messed up<br> <castastrophe> +1<br> <Rossen___> q?<br> <dael> AmeliaBR: Valid comment from oriol is sometimes things get confusing in syntax in that we don't just have comma sep list. We have a comma sep list followed by something else. Like BG where final includes the color which is different<br> <dbaron> Is the proposed rule "allow just one trailing comma", or will there be other extra commas allowed?<br> <dael> AmeliaBR: Will be some fiddly issues about getting best way to define w/o breaking.<br> <dael> AmeliaBR: More general concern about trailing commas?<br> <dael> TabAtkins: Note my comment that oriol concern isn't something to worry about. We already have poss of successive commas in grammer. If you have a # multiplier followed by extra comma it's invalid 2 commas next to<br> <AmeliaBR> s/comments are all messed up/commas are all messed up/<br> <dael> TabAtkins: General is # multipler for comma list allows trailing comma. Any property with explicit comma or function with explicit allows final comma after syntax.<br> <bradk> Google Meet has 1.6 stars (out of 5) in the iOS App Store<br> <dael> TabAtkins: I think that ends up covering everything. I think we can define w/o special case.<br> <dael> AmeliaBR: You'll write up?<br> <chris> sounds great, do it Tab<br> <dael> TabAtkins: Definitely. Very much in favor b/c JS supports this everywhere. I support having a similar syntax in CSS<br> <dael> florian: Anyone looked at compat?<br> <dael> TabAtkins: It makes invalid things possibly valid which we're usually fine with. B/C it looks weird if you're not doing it I woudl be surprised at accidental usage<br> <dael> florian: If you say it's in JS and people want it it seems there's demand for syntax and disappointed it doesn't work. Could be left in stray stylesheets. I'm concerned b/c if you're trying to do this on a whole bunch of properties and functions if it's compatable in most but not all we end up inconsistent<br> <dael> TabAtkins: I suspect number of cases is 0. Even if non-0 but low number I'm okay with it. As long as it's small number of weird cases jsut like we have some functions allowing 0deg without unit I'm okay with a few exceptions. I don't think we'll need to<br> <dael> chris: Benefit outweighs risk of an oops somewhere.<br> <dael> emilio: Does that allow inside [missed]?<br> <dael> TabAtkins: I think it should. For same reason to allow easy re-order I suspect it should allow<br> <dael> emilio: Seems weird to special case comma but I guess it's most common<br> <dael> TabAtkins: Only sep we use in this case.<br> <dael> TabAtkins: Slash is a one off. Not used like commas in a way it would benefit<br> <dael> fantasai: Underfined lengths is a space. THat's the other one<br> <fantasai> s/Underfined/The only other separator we use for lists of undefined/<br> <dael> florian: About selectors it does make me worry about compat. I've done it multiple times. Probably some stray ones where I forgot to remove and I doubt I'm alone<br> <dael> chris: Trying to get rid of commas but allowed like rgb with a trailing comma acceptable?<br> <dael> TabAtkins: Comma form of grammar, yes<br> <dael> TabAtkins: To florian point- reasonable. If it ends up being that we can't do selectors I'm okay with that.<br> <smfr> q+<br> <Rossen___> ack dbaron<br> <dael> dbaron: If we're going to do funt and selectors should we do media lists for @media?<br> <dael> TabAtkins: commas are allowed?<br> <dael> florian: Yeah, old syntax<br> <dael> dbaron: @supports doesn't have commas, but @media does<br> <dael> TabAtkins: Then yes, that too<br> <dbaron> s/funt/functions/<br> <Rossen___> ack smfr<br> <florian> s/old syntax/old syntax for "or"/<br> <dael> smfr: Seems weird to allow for bounded lists. If you do rgba it's weird for comma after. I guess this doesn't prop into computed style, right?<br> <fantasai> +1 to smfr<br> <dael> TabAtkins: COmputed style - correct we omit from serialization.<br> <dael> TabAtkins: First point, I don't agree limit to unbounded. In JS it's allowed in function arg which are usually bounded. Worthwhile to take long items and have trailing comma. I think it's reasonable here.<br> <dael> TabAtkins: True most color functions are short so no reason to put it there, but if everything else allows you want to be consistent<br> <dael> smfr: Mental model is comma is you can add an extra thing and tha'ts not bounded list<br> <dael> TabAtkins: Should be comma is a potential item. Basically same as ;. It separates properties but we think of it as an ender<br> <astearns> This seems like a good candidate for a preprocessor feature. Is it widely used in any preprocessors? If not, is that a reason not to add it to the language proper?<br> <dael> fremy: You can also re-order them. If the last one doesn't have a comma you have to rmove it. Even for lists where you can't add you can re-order arguments<br> <dael> drousso: What about when you can omit last semicolon in rule?<br> <dbaron> We also allow "color: red;;; background: blue"<br> <dael> TabAtkins: Can you elaborate in terms of the problem?<br> <dael> drousso: If you had something like a list of box-shadows as last rule. Allow trailing comma w/o semicolon after?<br> <dael> TabAtkins: Yes. Totally fine and not a syntax problem<br> <dael> drousso: okay<br> <dael> AmeliaBR: Closing brace is the endpoint. Comma has no special meaning<br> <dael> oriol: Concern with trailing comma if grammar has something after in the list. Could create ambig grammar. If you have a list of items sep by comma and at end you have a final optional item. Right now if value is a,b,c it's a 3 itme list. If you have a,b c you have c as final item<br> <AmeliaBR> example for Oriol's point: a `background: url(image.png), blue` is different from `background: url(image.png) blue`<br> <dael> oriol: Optional comma with a,b,c it's not clear if you ahve list of 3 items with last omitted or if there's 2 and the , after b is trailing.<br> <castastrophe> q: If the syntax is accepted, does that necessarily mean that's how it appears as the computed value? If you view the computed values of a property that has a function with a trailing comma, would the comma be stripped?<br> <dael> oriol: Not clear what we gain from allowing comma after any list. Better to allow at end of function bfore paran or value of property before ;<br> <fremy> @oriol: yeah, but that's bad design in the first case ^_^<br> <astearns> castastrophe: I heard earlier that the comma would be stripped from the computed value<br> <dael> TabAtkins: Case you outlined I don't believe exists in CSS. Ignoring comma it's a bad designt o have suffix implicitly sep<br> <dael> AmeliaBR: Have example, bg list<br> <castastrophe> astearns +1 makes sense<br> <dael> TabAtkins: Comma separates final layer. oriol talking about a # multiplier, a space, and than more stuff.<br> <astearns> q+<br> <dael> AmeliaBR: b/c bg list has a literal comma that literal comma would superceed the optional trailing comma for parsing any any other properties with that pattern need similar syntax?<br> <dael> TabAtkins: not quite. b/c literal comma it's comma sep list with final item having different grammer. In oriol we have comma sep list with than more stuff but no separator. Have to recognize list has ended. Could be less clear with final comma. If grammar of stuff and comma sep items is potenitally ambig looks like one more item in the list<br> <dael> TabAtkins: Theoretically valid, but I don't think we do it<br> <dael> dbaron: Similar is font shorthand. Explicitly the comma sep list is last<br> <dael> TabAtkins: We dot hat a few times. It's not made ambig by this. Suffix thing we don't do<br> <dbaron> (The font shorthand is a bad design, we shouldn't do that again.)<br> <dael> oriol: I think that we are not gaining anything by letting this and we get potantial ambig. If we allow trailing comma after trailing we get he same without the ambig.<br> <dael> TabAtkins: I think you're right. Given they're at the end of the grammar just allow at end if fine<br> <AmeliaBR> s/dot hat/do that/<br> <dael> emilio: Prefer that. Lower level we define the less random interop bugs we'll find. Like someone handling parsing forgot hte trailing comma. If we define they're at the end of the block that's much preferable than sprinkling it around<br> <castastrophe> What about putting together a table of examples?<br> <AmeliaBR> s/ any any/ and any/<br> <dael> Rossen___: Point of order. THere's a bit or excitement to have this. THere's a number of cases that have to be discussed before we see the final shape of where trailing commas are allowed. With that we can resolve on adding the trailing commas and see what details are after you've spec text<br> <dael> Rossen___: Also we have a queue.<br> <chris> q?<br> <dael> astearns: To back up a bit. I've heard people talking about details on how it's possible but didn't hear much about motivation so I'm not sure people are enthusiastic. Seems this could be a pre-processor feature and I"m not sure it's been impl. Does anyone use this for CSS in preprocessor?<br> <dael> TabAtkins: Do not know. This is preprocessorable<br> <dael> astearns: miriam says it works in sass<br> <jensimmons> could miriam talk about this a bit?<br> <dael> astearns: Should look at how it impl in sass and see if it's popular. If it's not popular don't know why we should add<br> <dael> TabAtkins: I was going to suggest, it was usuful to get general support. I'm happy to explore further in issue and get resolution later<br> <dael> miriam: I know it's popular in many sass places. I don't know all the use cases. Would have to look closer in where we allow it. THat can also happen later.<br> <dael> Rossen___: Great, thank you<br> <castastrophe> Now I'm wondering if postcss supports it<br> <dael> Rossen___: We'll get a resolution with a more concrete proposal. Ideally miriam you can help with sass popularity<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4968#issuecomment-617888183 using your GitHub account
Received on Wednesday, 22 April 2020 16:30:55 UTC