15:58:35 RRSAgent has joined #css 15:58:35 logging to http://www.w3.org/2016/07/13-css-irc 15:58:37 RRSAgent, make logs public 15:58:39 Zakim, this will be Style_CSS FP 15:58:39 ok, trackbot 15:58:40 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 15:58:40 Date: 13 July 2016 15:59:02 Rossen_ has changed the topic to: Agenda https://lists.w3.org/Archives/Public/www-style/2016Jul/0046.html 15:59:16 present+ 15:59:40 present+ 15:59:57 ScribeNick: dael 15:59:58 acp_antennahosue has joined #css 16:00:00 present+ dael 16:00:06 present+ 16:00:20 present+ antenna 16:00:30 acp_antennahouse has joined #css 16:00:37 present+ skk 16:01:17 present+ dauwhe 16:01:59 present+ ChrisL 16:02:20 present+ tgraham 16:02:52 alex_antennahouse has joined #css 16:03:07 Rossen_: Let's get started. 16:03:13 present+ jensimmons 16:03:16 Rossen_: As usual, a quick call for additional agenda items. 16:03:31 Topic: Upcoming F2F 16:03:49 Rossen_: We have TPAC coming up and than Redmond Washington in Jan and then Japan. 16:03:55 myles has joined #css 16:04:13 Rossen_: For Jan. those who want to book way ahead it would be good for us to settle on the week if not the actual date. All we have on the schedule right now is January. 16:04:14 present+ myles 16:04:27 Rossen_: Given that it will be in Redmond I'd like to hear throughts on timing. 16:04:34 fantasai: End of the week. Like Wed, THurs, Fri 16:04:39 +1 16:04:45 Rossen_: I don't have a problem with that. 16:05:04 Rossen_: Do people have restrictions on travel in terms of January. Prefer first or second half of January? 16:05:19 astearns: Anything becides the very first week is good with me. 16:05:37 Rossen_: Okay. I'm assuming a lot of people will be travelling that week. How about second half of January than? 16:05:39 I agree, the first week is too close to the holidays 16:05:45 Rossen_: Let me look at a calendar. 16:06:00 Rossen_: So if we do Wed, THurs, Fri it's 11, 12, and 13 or 18, 19, 20 16:06:06 SteveZ has joined #css 16:06:08 bkardell_ has joined #css 16:06:18 present+ 16:06:18 just FYI, Jan 20 is Inaguration Day in the U.S. 16:06:22 Rossen_: How about we settle on 18-20 provisionally for now. 16:06:25 present+ 16:06:29 fremy has joined #css 16:06:35 present+ 16:06:41 Rossen_: WE can revisit on the next two calls. 16:06:42 present+ leaverou 16:06:44 vollick has joined #css 16:06:50 present+ 16:06:50 Rossen_: What's inaguration day? 16:07:14 jensimmons: I just wanted to toss it out there as people may want to travel there. 16:07:28 Monday, January 16, is also a US holiday, but that's not a problem if we're meeting Wed-Thu-Fri 16:07:29 [snark from US people about presidential election] 16:07:59 Rossen_: Jan 16 is a holiday...okay, let's go back to 11-13. 16:08:00 *Inauguration (I mispelled above) 16:08:30 Rossen_: Other thing was please pick your travel to TPAC if you haven't. Hotels are starting to fill. 16:08:53 hober has joined #css 16:08:54 Rossen_: Finally the April/Spring F2F we provisionally had agreed on Japan. I wanted to at least figure out if we can target timeframe. 16:09:13 Rossen_: There were people in Japan wanting to org. in Tokyo. How is april preliminary 16:09:17 fantasai: I thought target May 16:09:43 Rossen_: If May and we want a meeting between May and TPAC...I think TPAC is late Oct. again. I think Halloween. THat will give us time inbetween 16:09:45 it may be easier for Hiroshi to organize a meeting in April rather than May 16:09:51 skk: Is it impossible to have it in April? 16:09:58 Rossen_: Everything is possible. We have to decide. 16:10:09 April in Japan is nice 16:10:12 skk: If I organize the F2F I prefer April because place and budget. 16:10:37 Sorry about the delay, I'm callignin now 16:10:40 Rossen_: So organizers prefer April. That gives us 3 months between F2f if it's tail end of April. 16:10:53 Rossen_: I'm not hearing opposition to late April meeting in Japan 16:11:06 Rossen_: We'll call this provisionally agreed upon and we'll revisit when we're a little closer. 16:11:18 Topci: Update os CSS-AAM 16:11:36 Sorry! 16:11:42 didn't realize i wasn't muted. 16:12:04 SteveZ has joined #css 16:12:17 present+ 16:12:17 Rossen_: The APA WG has been trying to...The APA started looking at our drafts. They have topics to dive deeper in an effort to start CSS-AAM 16:12:21 fucking hell, why is my call always echoy now? 16:12:25 Rossen_: I sent a link to the private list. 16:12:38 https://github.com/w3c/aria/wiki/CSS-AAM-Potential-Features 16:12:46 Rossen_: With that I wanted to open this for questions or concerns. 16:13:32 You want to avoid Golden Week in Japan which is april 29-May 6 16:13:42 ChrisL: I'd like to suggest this is a joint deliverable like we have with SVG. Having it be AAG only is a lot. If we work together we both have to sign off to publish and I think it's important to have adiquite CSS representation. Especially as we're about to redo the charter I'd like this as a joint deliverable 16:14:09 Rossen_: I agree. In past discussions I volunteered to work with the group on this. I'd be happy to continue and have this as joint. 16:14:39 Rossen_: There is an explicit paragraph I added to the coordination section of the charter that talks about that effort. I think the APA group is becoming more happy with our involement. 16:14:53 Rossen_: If you have concerns or want to participate let me know so we can organize. 16:15:01 move on 16:15:02 Rossen_: ChrisL did you want to add anything else? 16:15:12 https://github.com/w3c/csswg-drafts/issues/209 16:15:19 Topic: [css-grid] when to apply the clamping for fit-content() tracks? 16:15:29 Rossen_: Who wants this one? 16:15:53 smfr has joined #css 16:16:00 fantasai: THis is a technical issue on the impl of fit-content. We mad changes based on Mats pointing out previous defintiion wasn't sensible. I think this is resolved unless anyone wants to look specifically 16:16:04 present+ 16:16:10 fantasai: I can explain, but it goes into the grid sizing algo details. 16:16:25 Rossen_: I did review this issue. I don't think we have a problem with it. 16:16:38 Rossen_: But you added this to the agenda so I wans't sure if you wanted a resolution. 16:16:50 fantasai: Sure. I mainly wanted people that wanted to look at it to have a chance. 16:17:17 fantasai: Basically we added the definition recently and we were clamping at the end and we needed to do it at each step or spanning elements weren't handled correctly. 16:17:28 Rossen_: That makes sense. 16:17:52 Rossen_: Do we have other impl who would like to review this or should we resolve? 16:18:12 Rossen_: Sounds like we can reoslve 16:18:34 RESOLVED: Accept changes proposed here https://github.com/w3c/csswg-drafts/issues/209 to have fit-content() apply on every step of the algo instead of at the end. 16:18:47 Topic: [mediaqueries] Change dci-p3 back to p3 16:18:52 Rossen_: Whose is this? 16:18:53 q+ 16:18:53 https://github.com/w3c/csswg-drafts/issues/276 16:18:54 tantek has joined #css 16:19:33 I am in favour of changing back to 'p3' in MQ4 16:19:33 fantasai: could you mute? the background noise makes the call harder to hear 16:19:43 ChrisL: When the color gamut was added to MQ to detect screens doing mroe than srgb colors it was added generically. WE changed to dci-p3 to be more specific and match css colors 16:20:12 ChrisL: I think that's too specific for the MQ because it was intended to just say it can show more than srgb colors. So we think p3 is more correct than dci-p3 16:20:26 s/chrisl/?? 16:20:45 ChrisL: I agree. 16:20:50 s/??/smfr/ 16:21:04 Rossen_: I hear people in favor of the proposed change. smfr unless you have anything to add we can resolve 16:21:11 smfr: I don't have more to add 16:21:20 Rossen_: Objections to changing MQ to p3 from dci-p3? 16:21:30 https://github.com/w3c/csswg-drafts/issues/266 16:21:32 RESOLVED: Change MQ to p3 from dci-p3 16:21:38 astearns: Can you unmute me? I was the "anonymous echoer". 16:21:40 And I'll do the edit 16:21:44 Topic: [css-color] Unnecessary comma in color() 16:21:56 smfr: TabAtkins says he'll edit or dino will. 16:22:07 Rossen_: The comma topic. Who wants that. 16:22:51 Big question: which is better: color(foo .1 .2 .3 .4), color(foo .1 .2 .3, .4), color(foo .1 .2 .3 40%) 16:23:11 TabAtkins: that's a false dichotomy 16:23:13 ChrisL: There's been a bunch of discussion. It seems like a comma isn't needed syntatically for parsing. From a human reading side people say it's hard to tell. I think some people have argued for comma or slash. I don't entirely understand TabAtkins point. People in generally are asking for a way to tell where the alpha starts so I favor a seperator 16:23:54 sudden silence 16:23:59 rgba uses commas. As an author, I would expect this to be the same as that. 16:24:06 TabAtkins: My argument was a) functions should obay CSS syntax rules that don't use comma. For this sepecific thing where you have a not obvious number of arguments followed by an alpha if the alpha is numeric it makes it hard to read. I showed that in the thread. 16:24:14 s/obay/obey/ 16:24:55 TabAtkins: So it's nice to have a seperator. So have a comma or restrict opacity to a % and that makes it obvious. If there's a % that's your alpha. That's clearer to me than the comma and it does the same purpose. It makes it obvious to anyone if the color has an alpha. 16:24:58 FWIW I like the precentage solution 16:25:14 leaverou: It's inconsistant with any other color format. We need to accept numbers and percentages in that space 16:25:26 fremy, but we need to fix the old color functions to be compatible, too 16:25:42 TabAtkins: The color functions are crap syntax. No offence to whoever did it a while ago. They're different than CSS syntax. Consistancy is nice. 16:25:56 leaverou: I agree, but the ship has sailed. We can't stop having numbers as alpha 16:26:17 ChrisL: The commas between params were taken out a while ago. The comma between values and alpha is seperate. and the fallback. 16:26:32 TabAtkins: We're not discussing fallback The fallback can be intrinsically seperated from the rest. 16:26:35 ChrisL: Yeah, okay 16:26:54 TabAtkins: The same thing with name vs arguments. Only thing weird is telling alpha apart. 16:27:27 TabAtkins: I can live with comma-less and allow numberic and % alpha and if people read it it may be hard to tell. But that's their fault. 16:27:32 ChrisL: What aout /? 16:27:42 leaverou: I don't see it as intrinsically better than comma 16:27:55 prefer no comma (or slash), prefer percentage, can live with number as well (without comma) 16:28:00 TabAtkins: It's what we use to seperate things in a repitition group. I'd like to apply that in functions as well. 16:28:13 ChrisL: I'd like you to add that sentence to github. THat's very crisp. 16:28:28 TabAtkins: Yeah, okay. I think we had it in an old wiki, but I"m happy to write it. 16:28:35 https://wiki.csswg.org/ideas/functional-notation 16:28:51 TabAtkins: I'm okay with an alpha where you can choose number or % 16:29:09 leaverou: I think the main issue is if we keep numbers as alpha it's impossible to read if you don't know # of param 16:29:12 TabAtkins: So use % 16:29:24 ChrisL: The author may find it clear, but it's not the author that reads the stylesheet 16:29:43 leaverou: I can see why drop comma beween param, but an alpha is seperate info so it makes sense to sep by comma 16:30:05 TabAtkins: We don't use that anywhere else in CSS. THat only looks okay because you're used to seeing it elsewhere. 16:30:14 ChrisL: I think jensimmons had something in IRC 16:30:22 jensimmons: Why not seperate every value with a comma? 16:30:37 TabAtkins: No other CSS value works like that. Other legacy values do that, but we don't normally in CSS 16:30:46 leaverou: So normal CSS is what authors aren't using 16:30:55 ChrisL: You're saying CSS doens't do that but all other color things do 16:31:08 leaverou: Do graded colors use comma? 16:31:22 s/Do graded colors use comma?/Do gradient color stops not use commas now?/ 16:31:37 TabAtkins: The argument we should color color guidelines is that we should have color and colora and we clearly don't want to do that. So why should we be consistant with one thing and not another. 16:31:52 leaverou: Gradient color-stops are a repetition group, that's normal CSS comma usage. 16:31:53 jensimmons: I still don't feel it makes sense. They'll think of rgba nd rgba and be confused. 16:32:10 smfr: The use of % is flipped from rgba. It allows % for color and not alpha 16:32:14 TabAtkins: at
is not, it's just a separate piece of info 16:32:17 TabAtkins: That's why I'm fine with it being an option 16:32:52 (My preferred grammar is color( [ + | ] ? ? ).) 16:32:59 fantasai: I understand we want to make color consistant witht he rest of CSS, but also understand with the other color functions. I think the binding is closer to non-css colors. We can give the other colors a CSS-y syntax. THat's antoehr possibility. 16:33:25 fantasai: There's a certain amount of coor fixing we should do. Such as allowing RGB to take the other elements. IT would make all color functions more CSS-y 16:33:31 s/non-css colors/the css color functions/ 16:33:38 +1 to what fantasai said 16:34:02 ChrisL: Given we seem to have decided we want the color function to make the first argument optional and the default is srgb do we want to take the time to fix the existing ones? I can see pluses and minuses 16:34:15 fantasai: I think that might make a reasonable replacement for rgb, but not hsl. 16:34:17 yeah, that seems some non-zero work 16:34:23 ChrisL: Yes, I mean rgb, rgba and hash. 16:34:32 Chris's suggestion is that color(.1 .2 .3 .4) === rgba(10%, 20%, 30%, .4) 16:34:35 fantasai: If we allso hsl to be CSSy we shoudl be consistant and do it to rgb. 16:34:39 ChrisL: Hm. Yes. 16:34:57 ChrisL: TabAtkins I prefer color .1 .2 .3 40% 16:35:19 ChrisL: [missed] I think we should allow % because people are used to that 16:35:21 (I know your pref, I was just trying to be consistent in presentation, as much as possible.) 16:35:30 tantek has joined #css 16:35:34 fantasai: It seems there's a lot going on. 16:35:43 Strongly agree that color(.1 .2 .3 40%) is better 16:36:01 Strongly agree that color(.1 .2 .3 40%) is better as well 16:36:20 fantasai: So we've been discussing if color function should take commas, if rgb hsl and other should not take commas, we've discussed having the alpha be a number, % or either. So there's several things we need to decide on. 16:36:39 Rossen_: How do we move forward? 16:36:47 fantasai: I'll make a list in IRC and we'll go down the list. 16:36:54 1.) Whether alpha should be or or both? For just color() or all color functions including rgba etc.? 16:37:16 2.) Whether rgb() should be extended to allow an optional alpha. Likewise hsl() 16:37:41 3.) Whether commas are required between all color() arguments or not; if not, should rgb() etc. be allowed to drop comas? 16:38:07 3.a) If no commas between all arguments in color, should there be a separator for alpha? 16:38:24 fantasai: Were there other quesitons? 16:38:29 Rossen_: Is that the full list? 16:38:41 fantasai: I should split out 3 more. We can start on 1 while I typ 16:38:45 3.) Commas 16:38:46 s/typ/type 16:38:58 Rossen_: Opinions on #1? 16:39:13 3.1) Should color() have commas between all arguments or not? 16:39:16 jensimmons: Since we have number for alpha in other functions we should have it. People expect it to work that way 16:39:34 3.1) Should color() have commas between all arguments or not or optional? 16:39:40 1/ opinion: both, in all functions (but specs examples should use percentages) 16:39:43 TabAtkins: And I added % just in color 4 because it was stupid not to have it. I'm fine with the choice of both syntaxes. Alpha is # or % everywhere 16:39:54 agree alpha should be number or percentage 16:39:55 smfr: I agree with TabAtkins becuase it reduces congative load 16:39:57 leaverou: Yes. 16:39:59 both number and percent everywhere sounds cool to me 16:40:01 Rossen_: Reasonable to me as well. 16:40:03 +1 16:40:09 3.2) If commas are not required in color(), should they also be optional in other color functions like rgb()? 16:40:16 +1 to percentage *and* number 16:40:16 s/cognative/cognitive/ 16:40:18 +1 to or 16:40:20 Rossen_: Seems like people lean both for #1. Anyone against having both? 16:40:26 ok 16:40:49 RESOLVED: All alpha for color functions can be and 16:40:55 +++++++++1 16:41:03 3.3) If no commas in general, should there be a separator (of some kind) for alpha in the color functions()? 16:41:15 +1 16:41:18 leaverou: #2 authors make this mistake all the time. They add the 4th parameter and stuff breaks and they realize the didn't add the a. I'm very strongly in favor of this. 16:41:20 Agree exactly with what Lea said, matches my experience 100% 16:41:22 to optional alpha 16:41:31 +85% 16:41:43 smfr: I'm in favor but worried about compat What do we do with 4 now? 16:41:47 TabAtkins: Invalid and we drop. 16:41:51 TabAtkins: I can experiment and see 16:42:01 fantasai: So we accept unless web compat is a problem? 16:42:09 jensimmons: Does this make rgb and rgba identical? 16:42:17 fantasai: rgba requires alpha 16:42:32 ChrisL: If you have rgba and omit the fourth param do we make it 100%? 16:42:46 TabAtkins: We don't right now. But I'm nto super opposed to these being aliases. 16:43:12 s/right now/right now. It seems weird to drop the alpha, given it's rgbA()/ 16:43:16 ChrisL: Seems clearer. If we're chaning rgb to have an optional alpha that seems more consistant. If you do rgba and omit the 4th param we think you meant 100% 16:43:30 TabAtkins: I'm down this this. 16:43:39 I agree, sounds interesting and reasonable 16:43:55 Rossen_: So I'm hearing a lot of people in favor with the concern noted on figuring out compat risk. TabAtkins you can help with the compat check? 16:44:01 TabAtkins: I can look into that. 16:44:13 action TabAtkins figure out if there's compat risk on rgb() should be extended to allow an optional alpha. Likewise hsl() 16:44:13 Created ACTION-782 - Figure out if there's compat risk on rgb() should be extended to allow an optional alpha. likewise hsl() [on Tab Atkins Jr. - due 2016-07-20]. 16:44:21 fantasai: will you drop question 3 into IRC again? 16:44:31 3.) Commas 16:44:40 RESOLVED: rgb() should be extended to allow an optional alpha. Likewise hsl() pending compat analysis on TabAtkins 16:44:41 3.1) Should color() have commas between all arguments or not or optional? 16:44:48 3.2) If commas are not required in color(), should they also be optional in other color functions like rgb()? 16:44:53 plinss: Can we go back to #1? 16:44:57 3.3) If no commas in general, should there be a separator (of some kind) for alpha in the color functions()? 16:45:09 plinss: I thought we'd allow # and % everywhere including opacity? 16:45:14 TabAtkins: That is the state of the spec. 16:45:19 fantasai: Let's clarify that. 16:45:36 s/opacity/alpha/ 16:45:42 ChrisL: Yes, we should resolve that so the spec matches that. 16:45:50 plinss: Spec doesn't say that. 16:45:53 Rossen_: It should. 16:46:04 Rossen_: TabAtkins since you're editing can you take the action to update? 16:46:07 TabAtkins: Yes. 16:46:20 Rossen_: Anyone objecting to resolve that opacity also takes # or %? 16:46:34 RESOLVED: opacity also takes number or % 16:46:41 (The spec *does* already say that, so my action is now discharged. ^_^) 16:46:42 Rossen_: Coming back to the 3 items 16:46:45 fantasai: They're in IRC. 16:47:01 https://drafts.csswg.org/css-color/#transparency 16:47:08 Rossen_: 3.1, 3.2, and 3.3 are the options? 16:47:20 fantasai: They're questions. They related, but seperate to resolve on. 16:47:29 Rossen_: Okay, 3.1 16:47:56 ChrisL: I don't see anyone calling for commas between all arguments. It was in there originally, but the spec hasn't had commas since I fixed it weeks ago. 16:48:06 Rossen_: I think bradk who isn't on the call was in favor 16:48:08 jensimmons: I am. 16:48:24 jensimmons: I think it's confusing for this to be different than the other ones. 16:48:36 Rossen_: We have some author feedback that suggests otherwise 16:48:52 param comma-wsp? param 16:49:01 and there was a suggestion earlier that s/rgb/color/ should work in your stylesheet 16:49:35 +1 to what jensimmons said 16:49:39 jensimmons: This option to make them optional and take them out to try and get the industry to not do it in the future maybe that's a good idea. But shipping this new one that doesn't have commas when others do will trip people up. I feel like everybody does use commas in color so changing isn't trivial 16:49:48 Rossen_: But anyone with no experience will have consistancy 16:50:09 As I understand it, making comma optional in color would mean that color could not take a sequence of color values at some future time 16:50:27 fantasai: Even new people. All color functions have commas except this one. It makes sense to go away from that in the future, but given that we don't have color functions that drop commas allowing it here would be confusing. 16:50:33 SteveZ: ? Can you elaborate? 16:50:33 Rossen_: You did have an option to make them optional. 16:51:08 fantasai: I did that because one of the questions was do we take rgb and hsl and allow them to drop their commas. Than those functions have optional commas and color is consistant by having optional commas 16:51:25 TabAtkins: Optional commas are the most confusing thing possible and I hate them when they appear in SVG 16:51:29 Rossen_: I would not disagree 16:51:44 ChrisL: Yes. Sometimes the commas are optional and sometimes not and it's hard 16:52:10 Rossen_: So it seems like we've narrowed down to commas or no commas. I heard jensimmons and BradK advocate for commas. fantasai somewhat as well. 16:52:18 Rossen_: Let's call for objections to having commas 16:53:03 leaverou: While I'm for dropping the commas I see the compat argument. So I think it might be a good idea to have optional commas in the other color functions for legacy so they are eventually consistant and drop commas eventually. We can't drop them completely, but if they're optional in the other colors... 16:53:09 Rossen_: They can fade away on their own. 16:53:12 leaverou: Yeah. 16:53:23 Rossen_: THat was my thought on optional too, but people hated htem. 16:53:39 TabAtkins: I never want optional commas on a new thing. But for legacy to achieve our goal of no commas I'm okay. 16:53:52 Rossen_: That would be something to decide on 3.2 16:54:02 fantasai: I think 3.1 and 3.2 need to be together. They interact. 16:54:41 A) Commas are required among all arguments of all color functions (color(), rgb(), etc) 16:54:55 B) Commas are optional among all arguments of all color functions (color(), rgb(), etc.) 16:55:01 (Well, they don't influence each other for me. My answers are 1. No commas 2. Yes 3. No, regardless of how each individual one is decided.) 16:55:09 jensimmons: I feel there are two choices...or three. I'd like to see we require commas in color or we make rgb, hsl etc to be optional and we do color the same where they're optional. And if the WG want to write we suggest no commas and see if it takes off. I feel strongly the functions should be consistant. I guess the other is to make it no commas in color and optional elsewhere. 16:55:20 C) Commas are optional among all arguments of old color functions (rgb(), hsl()), but forbidden in color() 16:55:24 Rossen_: Which is our way to say get away from commas. We'll let you use them where you're used to it. 16:55:30 D) Commas are forbidden in all color functions (Ideal Solution Not Possible) 16:55:38 jensimmons: Yes. It means even 20 years from now people will wonder why there is different syntax. 16:55:52 Rossen_: I's rather move into a CSS consistant way than wonder about questions in 20 years. 16:56:10 I'm seriously not liking optional commas in color(...) 16:56:14 TabAtkins: And in 20 year arguments we should plan for waht we want it to look like. There may be legacy things in an appendix 16:56:36 jensimmons: So you make the optional commas so that people can move in that direction. 16:56:57 Rossen_: We will make them optional in RGB and other stuff. They'll be weak in old functions and not existin new ones 16:57:18 fantasai: THeres' 3 things to do. 4th would be get rid of all commas, but we can't do that. 16:57:22 vollick_ has joined #css 16:57:32 fantasai: 1) we require a comma everywhere. 16:57:58 fantasai: 2) commas optional on all color functions. This gives consistant syntax and has everything consistant 16:58:32 fantasai: 3) is commas optional on legacy and we forbid commas in color. This is the futherst we can go to the ideal but it creates inconsistancy in an entire class of commas. 16:58:52 fantasai: That's confusing to authors and I agree with jensimmons it's not a good idea. If we want optional commas it's fine. 16:59:05 s/class of commas/class of functions/ 16:59:09 plinss: If it's optional in new color we don't encourage movement toward no commas 16:59:18 Agree with plinss here. No reason to saddle new syntax with legacy weirdness. 16:59:20 well, there is a fourth on the table, the orginial argument 4) no commas in color(), commas required in rga hsl 16:59:28 Rossen_: I agree. We're allowing old decisions to hold on and not allowing moving forward. 16:59:42 jensimmons: OK, we'll call that E) :) 16:59:47 Rossen_: I like the list of three options. We have one minute. We can try and pick or move back to github. 16:59:59 1. retire commas 17:00:06 2. commas are optional everywhere in color funcs 17:00:09 Rossen_: I don't mind a quick straw poll on this list. 17:00:14 3. commas are optional in old funcs such as rbg() and drop the ones from new ones 17:00:24 fantasai: There's one more that's require commas in old and forbid them in color 17:00:27 4. commas are required in old funcs such as rbg() and drop the ones from new ones 17:00:32 jensimmons: That was the original proposal. 17:00:44 jensimmons: To me helping authors is more important than purity of code. 17:00:53 +1 to jen's statement 17:00:53 s/retire commas/require commas/ 17:01:15 (I'm in favor of commas: because rgb() and hsl() have them, lab(), lch() and rec2020() should, too. And I don't think commas are particularly ugly.) 17:01:27 I’d like us to vote for more than one if we like are ok with more than one option of the four 17:01:38 plinss: If allowing commas option in color we should allow optional commas in all CSS 17:02:12 plinss: I think that it will be more confusing to new authors. I think if we want to be fair to authors and see their needs first we should move the language to somewhere consistant and clean. 17:02:14 s/rec2020(/color(rec2020 / 17:02:15 Is it clear that moving to complicated microsyntaxes is actually a success? 17:02:29 fantasai: In some functions we need commas. 17:02:31 dbaron +1 17:02:33 or are simpler values and functions actually better for authors? 17:02:38 plinss: I'm only talking about commas with no purpose. 17:02:46 #notAllCommas 17:02:55 Straw poll! 17:03:00 cooloff 17:03:00 Rossen_: We're two mintutes over. Do we want a straw poll or come back next week? 17:03:02 i think it's time to go 17:03:10 ChrisL: Should like coming back is what we need to do. 17:03:16 leaverou: It's 3 minutes past the hour 17:03:24 Rossen_: Yeah. People want to go and think. 17:03:33 Rossen_: That was productive and ideally we can vote next week. 17:03:45 \^_^/ So happy for alpha~~~ 17:03:46 Rossen_: Thank you very much and we'll talk next week 17:03:56 in rgb() 17:03:57 er 17:03:59 rgba() 17:08:20 tantek_ has joined #css 17:12:05 tantek has joined #css 17:44:02 tantek_ has joined #css 17:52:13 teoli has joined #css 17:52:41 rrsagent, here 17:52:41 See http://www.w3.org/2016/07/13-css-irc#T17-52-41 18:27:03 trackbot, end meeting 18:27:03 Zakim, list attendees 18:27:03 As of this point the attendees have been tantek, Rossen, dholbert, eae, jihye, gregwhitworth, glazou, dauwhe, bradk, Florian, antonp, myles, dael, Rossen__, dbaron, tgraham, 18:27:06 ... myles_, antenna, astearns, plinss, alex_antennahouse, SteveZ, Bert, hober, iank_, rachelandrew, Rossen_, fantasai, fremy_, TabAtkins, vollick, ChrisL, smfr, zcorpan, antonp[, 18:27:06 ... fremy, plh, SteveZ_, MaRakow, joone, Liam_Quin, bkardell_, gsnedders, jensimmons, leaverou, skk, ++++++++1 18:27:11 RRSAgent, please draft minutes 18:27:11 I have made the request to generate http://www.w3.org/2016/07/13-css-minutes.html trackbot 18:27:12 RRSAgent, bye 18:27:12 I see no action items