- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 08 May 2020 00:02:32 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `#4968 Allow trailing comma in gradient functions (and probably others)`.
<details><summary>The full IRC log of that discussion</summary>
<dael> Topic: #4968 Allow trailing comma in gradient functions (and probably others)<br>
<dael> github: https://github.com/w3c/csswg-drafts/issues/4968<br>
<dael> TabAtkins: I think we're good. Previous hour was great and now we have a solid proposal.<br>
<dael> TabAtkins: I won't go over the whole thing, just look at issue<br>
<dael> TabAtkins: One concern from emilio during conversation is, WG in general suported trailing commas. Question was how. emilio concern was wanted it at low level, pref at parser so we didn't have to rely on impl remembering to put it in every place<br>
<dael> TabAtkins: At first thought it was weird and my first idea of a funct without a comma was attr and then I remembered it allows comma sep now. My idea of comma-less functions that get upgraded has happened<br>
<dael> TabAtkins: Same fo rpropreties, we've upgraded to be list valued. Some like color prob won't change, but we've done this in the past. My original objection is invalid, I support em<br>
<Rossen_> q<br>
<Rossen_> ack fantasai<br>
<dael> TabAtkins: I prop we adjust consume a declaration, a function, and a comma sep so in addition to dropping whitespace they can drop a single comma token from the end.<br>
<leaverou> +1, this will also make it easier to generate CSS<br>
<dael> TabAtkins: if you have a parse close to syntax this allows it anywhere without much effort<br>
<dael> TabAtkins: Syntax points: consume a declaration, consume a function, and new consume a comma sep list. All have an ammendment to consume a single comma token<br>
<dael> florian: Do you want to include conditional lists and selector lists?<br>
<dael> TabAtkins: Yes. the comma sep list thing was for those cases. I'd then redefine those to use that parsing algo.<br>
<dael> florian: I suspect compat issues for selectors but let's see<br>
<dael> florian: Properties that have comma sep list space and than a value do we have those?<br>
<dael> TabAtkins: Don't as far as I know but they wouldn't be covered by this change<br>
<myles> q+<br>
<dael> TabAtkins: Trailing comma is at the end of the entire property declaration. The algo isn't invoked for properties.<br>
<plinss> q+<br>
<dael> florian: Do we have prop with comma sep list / other comma sep list?<br>
<dael> TabAtkins: I don't think...<br>
<tantek> I'm looking forward to when we allow 2 trailing commas TBH. Maybe next year? Maybe every year we can add another optional trailing comma?<br>
<dael> fantasai: / is a more binding operator. If there are properties that have inverted the order of operation that's really bad. Comma is usually lowest<br>
<Rossen_> q<br>
<Rossen_> ack myles<br>
<dael> myles: Seems reasonable for us to have a sinlge value prop today that turns space sep tomorrow with 2 values where we wouldn't have a comma in the middle. If we allow comma in all today couldn't do that<br>
<dael> myles: Larger comment is commas make sense on lists not single value<br>
<dael> TabAtkins: If we change syntax from one value to two space sep a comma wouldn't interfere. We wouldn't do something like counter reset, that was a mistake<br>
<dael> myles: We use spaces and commas intentionally. Blanket stating for all doesn't seem forwardlooking<br>
<dael> TabAtkins: Looks forward compat. If it was a,; and than we accept a b a, is fine a b is fine<br>
<faceless2_> So "display: block,;" is valid?<br>
<dael> myles: Not about ambiguity, we diesgin properties and want a comma or not a comma<br>
<fantasai> yes, that's Tab's proposal<br>
<dael> TabAtkins: Okay. objection to that, across css comma has been consistantly sept between repetitions of a list.<br>
<dael> fantasai: Not true<br>
<dael> fantasai: A lot of our funct it's not a list of thing.<br>
<dael> TabAtkins: That's why I said properties.<br>
<Rossen_> q?<br>
<dael> TabAtkins: B/c consistant meaning there and trailing comma fine at end of one element list and not going to give comma another meaning when in a trailing position i don't think it's a forward compat issue<br>
<dael> plinss: In favor but one concern.<br>
<Rossen_> ack plinss<br>
<dael> plinss: If you say foo, and nothing. If we define the second thing gets default value and it's important there are 2 things that's broken<br>
<dael> TabAtkins: We would not define a repetition can be completely empty. We don't do that today. A value and atrailing comma is single value<br>
<dael> plinss: This forces us into never allowing that. Never allow blank after comma is set in stone.<br>
<dael> TabAtkins: Agree<br>
<dael> AmeliaBR: How effect parsing of custom properties. When do we drop the comma? could be meaningful at end<br>
<dael> TabAtkins: dropped during parsing. I can see it being confusing but I'm of the opinion that if you're putting structural stuff like that in your variable I think you'd in a world of pain<br>
<emilio> q+<br>
<dael> AmeliaBR: Real use cases where want custom property to be a list of repetitions or a blank. In that case don't want comma where you use custom property b/c invalid if it's a blank.<br>
<dael> florian: Can we make an exception?<br>
<dael> TabAtkins: Doable. A bit weird but not out of question<br>
<dael> florian: Since it's a list of tokens it's a natural exception<br>
<dael> AmeliaBR: Have an exception where a blank is meaningful<br>
<dael> TabAtkins: That's not parser lever<br>
<Rossen_> ack emilio<br>
<dael> emilio: Not sure initial answer was correct. Parsing at property consumes all tokens regardless of which.<br>
<dael> TabAtkins: Depends on definition. Id on't care what declarations name is while I'm consuming so parse the same and than apply grammar. I know browsers do grammer as you go but it's must simpler mental. That's why I'm okay adding a check for it it's parsed.<br>
<dael> Rossen_: Time check, this will take us to the end. We have a queue and then let's see if we can end<br>
<Rossen_> ack fantasai<br>
<Zakim> fantasai, you wanted to ask for comparison between the two proposals<br>
<oriol> q+<br>
<dael> fantasai: Wanted to ask if we weren't going to do this for everything the alternative is only where there is a list. If we drew that up what would it look like and should we compare?<br>
<dael> TabAtkins: Complicated. SImpliest is # multiplier allows trailing comma. BUt anything that does commas explicitly which is a lot would not work.<br>
<dael> TabAtkins: Have to go into every prop that uses commas and make sure their grammer expresses it.<br>
<dael> myles: I think that makes sense. Property by property is right<br>
<dael> drousso: I agree<br>
<faceless2_> +1 to myles<br>
<Rossen_> Zakim, close queue<br>
<Zakim> ok, Rossen_, the speaker queue is closed<br>
<astearns> terrible to do things property by property for authors<br>
<dael> TabAtkins: Disagree b/c it's fine and reasonable to do commas at end of single in JS. Having to distinguish for a way to write it easily seems unnecessary burdon on authors<br>
<myles> q+<br>
<Rossen_> q?<br>
<dael> florian: I don't like it for rollout, if this is centeral it is fixed once. If it's property by property a fix would end up going out in some places but not all<br>
<dael> myles: Difference between css and js is parsing rule isn't different by property in js. I don't understand argument that js has it in function calls so we have it everywhere<br>
<dael> TabAtkins: Not strict, but reasoning is similar<br>
<dael> oriol: Ask about trailing comma. In case there's an ! and if it's before the !important or if at very end<br>
<dael> TabAtkins: Before the !important. End of value space and ! flag is after that<br>
<dael> TabAtkins: I'd like to prop a resolution ad see if objections.<br>
<florian> +1<br>
<dael> TabAtkins: Prop: I make the syntax spec changes to allow trailing commas in general module small changes around things like !imoprtant<br>
<dael> Rossen_: Obj?<br>
<tantek> ES also allows it in arrays e.g. test =[1,2,]<br>
<dael> myles: I'm not going to object but seems wrong direction<br>
<tantek> not just functions, as a correction to myles's assertion that it's only functions<br>
<TabAtkins> ES allows it *everywhere* now, yeah. [1,2,], {foo,bar,}, and foo(a,b,)<br>
<dael> fantasai: Alternative way forward is TabAtkins has his prop and myles if you think there's a better way you can draft a proposal and we compare<br>
<tantek> Thanks TabAtkins<br>
<dael> emilio: Would myles agree on functions only and decide declarations at another time?<br>
<dael> myles: Yes. Commas at end of lists is valuable<br>
<dael> Rossen_: TabAtkins ?<br>
<dael> TabAtkins: I think myles wants opposite of emilio<br>
<drousso> that's not true TabAtkins something like `let x = 2,;` is not valid<br>
<drousso> it's only allowed in places where a sequence/list/"multitude" is expected<br>
<dael> emilio: Can we defer deciding if we add trailing commas for all declarations and agree we do it for comma separated list and function arguments?<br>
<TabAtkins> drousso: Hm, time for a new ES proposal<br>
<drousso> strong disagreee<br>
<dael> florian: I think iw ould object property by property<br>
<dael> fantasai: I prop that TabAtkins drafts a more specific proposal and myles and emilio discuss drafting a different proposal<br>
<dael> TabAtkins: myles are you okay with trailing commas on functions?<br>
<dael> myles: No opinions<br>
<dael> TabAtkins: Let's resolve on that<br>
<dael> smfr: Lists first<br>
<dael> fantasai: Let's come back with something written specifically<br>
<dael> Rossen_: I think that's be best path forward. Let's nto resolve by exhaustion. TabAtkins write your proposal. emilio and myles if you want a short at your proposal go ahead and draft that.<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-625556792 using your GitHub account
Received on Friday, 8 May 2020 00:02:35 UTC