- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 13 Jul 2016 21:00:06 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Upcoming F2F Meetings
---------------------
- Anyone who has not done so should book for TPAC soon as hotels
are filling up.
- The dates for the January 2017 F2F are tentatively set as the
11th, 12th, and 13th. Anyone with problems for these dates
should raise their concern in the next two weeks on a call or
on the mailing list.
- The spring meeting will be in Japan. On the call late April was
suggested, but afterwards in IRC it was brought up that Golden
Week (April 29-May 6) needs to be avoided and that there are
US school holidays in that time period that may also need to
be avoided.
Update on CSS-AAM progress and APAWG coordination
-------------------------------------------------
- There was a strong desire to ensure that CSS-AAM is done as a
joint effort.
- Rossen indicated the coordination on this was a part of the new
CSSWG charter.
When to apply the clamping for fit-content() tracks?
----------------------------------------------------
- RESOLVED: Accept changes proposed here:
https://github.com/w3c/csswg-drafts/issues/209 to have
fit-content() apply on every step of the algorithm
instead of at the end.
Change dci-p3 back to p3
------------------------
- RESOLVED: Change MQ4 to p3 from dci-p3
Unnecessary comma in color()
----------------------------
- RESOLVED: All alpha for color functions can be <number> and
<percentage>
- RESOLVED: Opacity also takes <number> or <percentage>
- RESOLVED: rgb() should be extended to allow an optional alpha.
Likewise hsl(). Pending compat analysis by TabAtkins
- There was not a decision reached on if commas should be, should
not be, or should optionally be present in color() nor in
other color functions like rgb() and hsl(). There were four
options on the table for the group to discuss on github and
revisit for voting next week. They are:
1. always require commas
2. commas are optional everywhere in color functions
3. commas are optional in old functions such as rbg() and drop
the ones from new ones
4. commas are required in old functions such as rbg() and drop
the ones from new ones
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Jul/0046.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
Bert Bos
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Tony Graham
Dael Jackson
Brian Kardell
Ian Kilpatrick
Chris Lilley
Peter Linss
Myles Maxfield
François Remy
Hiroshi Sakakibara
Jen Simmons
Lea Verou
Ian Vollick
Steve Zilles
Regrets:
Tantek Çelik
Daniel Glazman
Dean Jackson
Brad Kemper
Michael Miller
Florian Rivoal
Greg Whitworth
Scribe: dael
Upcoming F2F Meetings
---------------------
Rossen: Let's get started.
Rossen: As usual, a quick call for additional agenda items.
Rossen: We have TPAC coming up and then Redmond, Washington in
January and then Japan.
Rossen: For January for 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.
Rossen: Given that it will be in Redmond I'd like to hear thoughts
on timing.
fantasai: End of the week. Like Wednesday, Thursday, Friday.
<dael> +1
Rossen: I don't have a problem with that.
Rossen: Do people have restrictions on travel in terms of January.
Prefer first or second half of January?
astearns: Anything besides the very first week is good with me.
<jensimmons> I agree, the first week is too close to the holidays
Rossen: Okay. I'm assuming a lot of people will be traveling that
week. How about second half of January then?
Rossen: Let me look at a calendar.
Rossen: So if we do Wednesday, Thursday, Friday it's 11, 12, and
13 or 18, 19, and 20
<jensimmons> just FYI, Jan 20 is Inauguration Day in the U.S.
Rossen: How about we settle on 18-20 provisionally for now?
Rossen: We can revisit on the next two calls.
Rossen: What's inauguration day?
jensimmons: I just wanted to toss it out there as people may want
to travel there.
<dbaron> Monday, January 16, is also a US holiday, but that's not
a problem if we're meeting Wed-Thu-Fri
Rossen: Jan 16 is a holiday...okay, let's go back to 11-13.
Rossen: Other thing was please pick your travel to TPAC if you
haven't. Hotels are starting to fill.
Rossen: Finally the April/Spring F2F we provisionally had agreed
on Japan. I wanted to at least figure out if we can target
time frame.
* fantasai thought we were aiming for May.
<dauwhe> I thought May too.
Rossen: There were people in Japan wanting to organize in Tokyo.
How is April preliminary?
fantasai: I thought we decided to target May.
Rossen: If May and we want a meeting between May and TPAC...I
think TPAC is late October again. I think Halloween. That
will give us time in between.
<astearns> it may be easier for Hiroshi to organize a meeting in
April rather than May
skk: Is it impossible to have it in April?
Rossen: Everything is possible. We have to decide.
<ChrisL> April in Japan is nice
skk: If I organize the F2F I prefer April because place and budget.
* fantasai has a preference for May...
Rossen: So organizers prefer April. That gives us 3 months between
F2Fs if it's tail end of April.
Rossen: I'm not hearing opposition to late April meeting in Japan.
Rossen: We'll call this provisionally agreed upon and we'll
revisit when we're a little closer.
<skk> too much late April is not so good, because Japanese long
vacation has there. (called Golden Week, in Japan)
<dauwhe> April 17-21 is school vacation week in some of the US
<fantasai> skk, what about mid/late May?
<SteveZ> You want to avoid Golden Week in Japan which is April
29-May 6
<skk> fantasai, hmmm, March is the end of year in Japan. April is
OK, because we can say 'there are some schedule delay'. But
mid/late May is a bit difficult ...
Update on CSS-AAM progress and APAWG coordination
-------------------------------------------------
Rossen: The APAWG has been trying to...The APA started looking at
our drafts. They have topics to dive deeper in an effort
to start CSS-AAM
Rossen: I sent a link to the private list.
<Rossen> https://github.com/w3c/aria/wiki/CSS-AAM-Potential-Features
Rossen: With that I wanted to open this for questions or concerns.
ChrisL: I'd like to suggest this is a joint deliverable like we
have with SVG. Having it be APA only is a lot. If we work
together we both have to sign off to publish and I think
it's important to have adequate CSS representation.
Especially as we're about to redo the charter I'd like
this as a joint deliverable.
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.
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
involvement.
Rossen: If you have concerns or want to participate let me know so
we can organize.
Rossen: ChrisL did you want to add anything else?
<ChrisL> move on
When to apply the clamping for fit-content() tracks? [css-grid]
---------------------------------------------------------------
<Rossen> https://github.com/w3c/csswg-drafts/issues/209
Rossen: Who wants this one?
fantasai: This is a technical issue on the implementation of
fit-content(). We made changes based on Mats pointing
out previous definition wasn't sensible. I think this is
resolved unless anyone wants to look specifically.
fantasai: I can explain, but it goes into the grid sizing
algorithm details.
Rossen: I did review this issue. I don't think we have a problem
with it.
Rossen: But you added this to the agenda so I wasn't sure if you
wanted a resolution.
fantasai: Sure. I mainly wanted people that wanted to look at it
to have a chance.
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.
Rossen: That makes sense.
Rossen: Do we have other implementors who would like to review
this or should we resolve?
Rossen: Sounds like we can resolve.
RESOLVED: Accept changes proposed here:
https://github.com/w3c/csswg-drafts/issues/209 to have
fit-content() apply on every step of the algorithm
instead of at the end.
Change dci-p3 back to p3 [mediaqueries]
---------------------------------------
<Rossen> https://github.com/w3c/csswg-drafts/issues/276
Rossen: Whose is this?
<ChrisL> I am in favour of changing back to 'p3' in MQ4
smfr: When the color gamut was added to MQ to detect screens doing
more than srgb() colors it was added generically. We changed
to dci-p3 to be more specific and match css colors.
smfr: 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.
ChrisL: I agree.
Rossen: I hear people in favor of the proposed change. smfr unless
you have anything to add we can resolve.
smfr: I don't have more to add.
Rossen: Objections to changing MQ to p3 from dci-p3?
RESOLVED: Change MQ to p3 from dci-p3
<TabAtkins> And I'll do the edit
smfr: TabAtkins says he'll edit or dino will.
Unnecessary comma in color() [css-color]
----------------------------------------
<Rossen> https://github.com/w3c/csswg-drafts/issues/266
Rossen: The comma topic. Who wants that?
<TabAtkins> Big question: which is better: color(foo .1 .2 .3 .4),
color(foo .1 .2 .3, .4), color(foo .1 .2 .3 40%)
<leaverou> TabAtkins: that's a false dichotomy
ChrisL: There's been a bunch of discussion. It seems like a comma
isn't needed syntactically 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 general are asking
for a way to tell where the alpha starts so I favor a
separator.
<jensimmons> rgba() uses commas. As an author, I would expect this
to be the same as that.
TabAtkins: My argument was functions should obey CSS syntax
rules that don't use comma. For this specific 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.
TabAtkins: So it's nice to have a separator. So have a comma or
restrict opacity to a percent and that makes it
obvious. If there's a percent 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.
<fremy> FWIW I like the precentage solution
<fantasai> too
<fantasai> fremy, but we need to fix the old color functions to be
compatible, too
leaverou: It's inconsistent with any other color format. We need
to accept numbers and percentages in that space.
TabAtkins: The color functions are crap syntax. No offense to
whoever did it a while ago. They're different than CSS
syntax. Consistency is nice.
leaverou: I agree, but the ship has sailed. We can't stop having
numbers as alpha.
ChrisL: The commas between parameters were taken out a while ago.
The comma between values and alpha is separate. and the
fallback.
* fantasai is a bit confused now
TabAtkins: We're not discussing fallback. The fallback can be
intrinsically separated from the rest.
ChrisL: Yeah, okay.
TabAtkins: The same thing with name vs arguments. Only thing weird
is telling alpha apart.
<fantasai> TabAtkins, can you post the syntax proposal into IRC in
grammar notation?
TabAtkins: I can live with comma-less and allow numeric and
percent alpha and if people read it it may be hard to
tell. But that's their fault.
<astearns> prefer no comma (or slash), prefer percentage, can live
with number as well (without comma)
ChrisL: What about slash?
leaverou: I don't see it as intrinsically better than comma.
TabAtkins: It's what we use to separate things in a repetition
group. I'd like to apply that in functions as well.
ChrisL: I'd like you to add that sentence to github. That's very
crisp.
TabAtkins: Yeah, okay. I think we had it in an old wiki, but I'm
happy to write it.
<fantasai> https://wiki.csswg.org/ideas/functional-notation
TabAtkins: I'm okay with an alpha where you can choose number or
percentage
leaverou: I think the main issue is if we keep numbers as alpha
it's impossible to read if you don't know number of
parameters,
TabAtkins: So use percentage.
ChrisL: The author may find it clear, but it's not the author that
reads the stylesheet.
leaverou: I can see why drop comma between parameters, but an
alpha is separate info so it makes sense to separated by
comma.
TabAtkins: We don't use that anywhere else in CSS. That only looks
okay because you're used to seeing it elsewhere.
ChrisL: I think jensimmons had something in IRC.
jensimmons: Why not separate every value with a comma?
TabAtkins: No other CSS value works like that. Other legacy values
do that, but we don't normally in CSS.
leaverou: So normal CSS is what authors aren't using.
ChrisL: You're saying CSS doesn't do that but all other color
things do.
leaverou: Do gradient color stops not use commas now?
TabAtkins: The argument we should have on color guidelines is that
we should have color and colora and we clearly don't
want to do that. So why should we be consistent with
one thing and not another.
<TabAtkins> leaverou: Gradient color-stops are a repetition group,
that's normal CSS comma usage.
<leaverou> TabAtkins: <shape> at <center> is not, it's just a
separate piece of info
jensimmons: I still don't feel it makes sense. They'll think of
rgb() and rgba() and be confused.
smfr: The use of percentage is flipped from rgba(). It allows
percentage for color and not alpha.
TabAtkins: That's why I'm fine with it being an option.
<TabAtkins> (My preferred grammar is color( <ident> [ <number>+ |
<string> ] <alpha-value>? <fallback-color>? ).)
fantasai: I understand we want to make color consistent with the
rest of CSS, but also understand with the other color
functions. I think the binding is closer to the css
color functions. We can give the other colors a CSS-y
syntax. That's another possibility.
fantasai: There's a certain amount of color fixing we should do.
Such as allowing RGB() to take the other elements. It
would make all color functions more CSS-y.
<jensimmons> +1 to what fantasai said
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.
fantasai: I think that might make a reasonable replacement for
rgb(), but not hsl().
<fremy> yeah, that seems some non-zero work
ChrisL: Yes, I mean rgb(), rgba() and hash.
<TabAtkins> Chris's suggestion is that color(.1 .2 .3 .4) ===
rgba(10%, 20%, 30%, .4)
fantasai: If we also make hsl() to be CSS-y we should be
consistent and do it to rgb.
ChrisL: Hm. Yes.
ChrisL: TabAtkins I prefer color(.1 .2 .3 40%)
ChrisL: [missed] I think we should allow % because people are used
to that.
<TabAtkins> (I know your pref, I was just trying to be consistent
in presentation, as much as possible.)
<TabAtkins> Strongly agree that color(.1 .2 .3 40%) is better
<ChrisL> Strongly agree that color(.1 .2 .3 40%) is better as well
fantasai: It seems there's a lot going on.
fantasai: So we've been discussing if color function should take
commas, if rgb, hsl, and other colors should not take
commas, we've discussed having the alpha be a number,
percentage or either. So there's several things we need
to decide on.
Rossen: How do we move forward?
fantasai: I'll make a list in IRC and we'll go down the list.
<fantasai> 1.) Whether alpha should be <number> or <percentage> or
both? For just color() or all color functions
including rgba() etc.?
<fantasai> 2.) Whether rgb() should be extended to allow an
optional alpha. Likewise hsl()
<fantasai> 3.) Whether commas are required between all color()
arguments or not; if not, should rgb() etc. be
allowed to drop comas?
<fantasai> 3.a) If no commas between all arguments in color,
should there be a separator for alpha?
fantasai: Were there other questions?
Rossen: Is that the full list?
fantasai: I should split out 3 more. We can start on 1 while I
type.
<fantasai> 3.) Commas
<fantasai> 3.1) Should color() have commas between all arguments
or not or optional?
<fantasai> 3.2) If commas are not required in color(), should they
also be optional in other color functions like
rgb()?
<fantasai> 3.3) If no commas in general, should there be a
separator (of some kind) for alpha in the color
functions()?
Rossen: Opinions on #1?
jensimmons: Since we have number for alpha in other functions we
should have it. People expect it to work that way
<fremy> opinion: both, in all functions (but specs examples should
use percentages)
TabAtkins: And I added percentage just in color 4 because it was
stupid not to have it. I'm fine with the choice of both
syntaxes. Alpha is number or percentage everywhere
<SteveZ> agree alpha should be number or percentage
smfr: I agree with TabAtkins because it reduces cognitive load.
leaverou: Yes.
<jensimmons> both number and percent everywhere sounds cool to me
Rossen: Reasonable to me as well.
<plinss> +1
<Bert> +1 to percentage *and* number
<fantasai> +1 to <number> or <percentage>
Rossen: Seems like people lean both for #1. Anyone against having
both?
<ChrisL> ok
<TabAtkins> +++++++++1
RESOLVED: All alpha for color functions can be <number> and
<percentage>
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.
<TabAtkins> Agree exactly with what Lea said, matches my
experience 100%
<fantasai> +1 to optional alpha
<astearns> +85%
smfr: I'm in favor but worried about compat. What do we do with 4
values on rgb() now?
TabAtkins: Invalid and we drop.
TabAtkins: I can experiment and see on compat.
fantasai: So we accept unless web compat is a problem?
jensimmons: Does this make rgb() and rgba() identical?
fantasai: rgba() requires alpha
ChrisL: If you have rgba() and omit the fourth param do we make it
100%?
TabAtkins: We don't right now. It seems weird to drop the alpha,
given it's rgbA(). But I'm not super opposed to these
being aliases.
ChrisL: Seems clearer. If we're changing rgb() to have an optional
alpha that seems more consistent. If you do rgba() and
omit the 4th param we think you meant 100%.
TabAtkins: I'm down this this.
<jensimmons> I agree, sounds interesting and reasonable
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?
TabAtkins: I can look into that.
ACTION TabAtkins figure out if there's compat risk on "rgb()
should be extended to allow an optional alpha. Likewise
hsl()"
<trackbot> Created ACTION-782
RESOLVED: rgb() should be extended to allow an optional alpha.
Likewise hsl(). Pending compat analysis on TabAtkins
plinss: Can we go back to #1?
plinss: I thought we'd allow number and percent everywhere
including opacity?
TabAtkins: That is the state of the spec.
fantasai: Let's clarify that.
ChrisL: Yes, we should resolve that so the spec matches that.
plinss: Spec doesn't say that.
Rossen: It should.
Rossen: TabAtkins since you're editing can you take the action to
update?
TabAtkins: Yes.
Rossen: Anyone objecting to resolve that opacity also takes number
or percentage?
RESOLVED: opacity also takes <number> or <percentage>
<TabAtkins> https://drafts.csswg.org/css-color/#transparency
<fantasai> 3.) Commas
<fantasai> 3.1) Should color() have commas between all arguments
or not or optional?
<fantasai> 3.2) If commas are not required in color(), should they
also be optional in other color functions like
rgb()?
<fantasai> 3.3) If no commas in general, should there be a
separator (of some kind) for alpha in the color
functions()?
Rossen: Coming back to the #3 items
fantasai: They're in IRC.
Rossen: 3.1, 3.2, and 3.3 are the options?
fantasai: They're questions. They related, but separate to resolve
on.
Rossen: Okay, 3.1.
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.
Rossen: I think bradk who isn't on the call was in favor.
jensimmons: I am.
jensimmons: I think it's confusing for this to be different than
the other ones.
Rossen: We have some author feedback that suggests otherwise
<ChrisL> param comma-wsp? param
<astearns> and there was a suggestion earlier that s/rgb/color/
should work in your stylesheet
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
<fantasai> +1 to what jensimmons said
Rossen: But anyone with no experience will have consistency.
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.
<SteveZ> 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
<TabAtkins> SteveZ: ? Can you elaborate?
Rossen: You did have an option to make them optional.
fantasai: I did that because one of the questions was do we take
rgb() and hsl() and allow them to drop their commas.
Then those functions have optional commas and color is
consistent by having optional commas.
TabAtkins: Optional commas are the most confusing thing possible
and I hate them when they appear in SVG.
Rossen: I would not disagree.
ChrisL: Yes. Sometimes the commas are optional and sometimes not
and it's hard.
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.
Rossen: Let's call for objections to having commas
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 consistent and drop commas
eventually. We can't drop them completely, but if
they're optional in the other colors...
Rossen: They can fade away on their own.
leaverou: Yeah.
Rossen: That was my thought on optional too, but people hated them.
TabAtkins: I never want optional commas on a new thing. But for
legacy to achieve our goal of no commas I'm okay.
Rossen: That would be something to decide on 3.2
fantasai: I think 3.1 and 3.2 need to be together. They interact.
<TabAtkins> (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.)
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 wants to write we
suggest no commas and see if it takes off. I feel
strongly the functions should be consistent. I guess
the other is to make it no commas in color and
optional elsewhere.
Rossen: Which is our way to say get away from commas. We'll let
you use them where you're used to it.
jensimmons: Yes. It means even 20 years from now people will
wonder why there is different syntax.
Rossen: I'd rather move into a CSS consistent way than wonder
about questions in 20 years.
TabAtkins: And in 20 year argument is we should plan for what we
want it to look like. There may be legacy things in an
appendix.
jensimmons: So you make the optional commas so that people can
move in that direction.
Rossen: We will make them optional in RGB() and other stuff.
They'll be weak in old functions and not existing in new
ones.
<fremy> I'm seriously not liking optional commas in color(...)
<fantasai> A) Commas are required among all arguments of all color
functions (color(), rgb(), etc)
<fantasai> B) Commas are optional among all arguments of all color
functions (color(), rgb(), etc.)
<fantasai> C) Commas are optional among all arguments of old color
functions (rgb(), hsl()), but forbidden in color()
<fantasai> D) Commas are forbidden in all color functions (Ideal
Solution Not Possible)
fantasai: There's 3 things to do. 4th would be get rid of all
commas, but we can't do that.
fantasai: A) we require a comma everywhere.
fantasai: B) commas optional on all color functions. This gives
consistent syntax and has everything consistent.
fantasai: C) is commas optional on legacy and we forbid commas in
color. This is the furthest we can go to the ideal
but it creates inconsistency in an entire class of
functions.
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.
plinss: If it's optional in new color we don't encourage movement
toward no commas.
<TabAtkins> Agree with plinss here. No reason to saddle new syntax
with legacy weirdness.
Rossen: I agree. We're allowing old decisions to hold on and not
allowing moving forward.
<jensimmons> well, there is a fourth on the table, the original
argument 4) no commas in color(), commas required in
rgba() hsl()
<fantasai> jensimmons: OK, we'll call that E) :)
Rossen: I like the list of three options. We have one minute. We
can try and pick or move back to github.
Rossen: I don't mind a quick straw poll on this list.
fantasai: There's one more that's require commas in old and forbid
them in color.
jensimmons: That was the original proposal.
<Rossen> 1. require commas
<Rossen> 2. commas are optional everywhere in color funcs
<Rossen> 3. commas are optional in old funcs such as rbg() and
drop the ones from new ones
<Rossen> 4. commas are required in old funcs such as rbg() and
drop the ones from new ones
jensimmons: To me helping authors is more important than purity of
code.
<SteveZ> +1 to jen's statement
<dauwhe> jensimmons: +1 on priority of constituencies!
<Bert> (I'm in favor of commas: because rgb() and hsl() have them,
lab(), lch() and color(rec2020) should, too. And I don't
think commas are particularly ugly.)
<jensimmons> I’d like us to vote for more than one if we like are
ok with more than one option of the four
plinss: If allowing commas option in color we should allow
optional commas in all CSS.
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 consistent
and clean.
fantasai: In some functions we need commas.
plinss: I'm only talking about commas with no purpose.
<dbaron> Is it clear that moving to complicated microsyntaxes is
actually a success?
<ChrisL> dbaron +1
<dbaron> or are simpler values and functions actually better for
authors?
Rossen: We're two minutes over. Do we want a straw poll or come
back next week?
<TabAtkins> Straw poll!
<SteveZ> cooloff
ChrisL: Coming back is what we need to do.
leaverou: It's 3 minutes past the hour
Rossen: Yeah. People want to go and think.
Rossen: That was productive and ideally we can vote next week.
Rossen: Thank you very much and we'll talk next week.
Received on Thursday, 14 July 2016 01:01:06 UTC