W3C home > Mailing lists > Public > www-style@w3.org > July 2016

[CSSWG] Minutes Telecon 2016-07-13 [css-grid] [mediaqueries] [css-color]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 13 Jul 2016 21:00:06 -0400
Message-ID: <CADhPm3txZEGRqujAgGgpGgYf5gkON9HJhZVmVkPTLtR9FjeeCQ@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Thursday, 14 July 2016 01:01:07 UTC