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

[CSSWG] San Francisco F2F 2016-05-11 Part IV: CSS Color, Grid, Flexbox, Inline [css-color] [css-grid] [css-flexbox] [css-inline]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 7 Jun 2016 21:25:37 +0300
Message-ID: <CADhPm3vN5mUas4zeu5fiaddh_U9EtZ3ZyRrHmCgvykC_GzTqMw@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.

CSS Color

  - There were several actions recorded to make improvements to the
      spec. They were to:
      - add note explaining a reasonable range for C in lch() to the
      - remove commas between in the color() examples
      - fix Rec.2020 and Rec2020 to be rec2020, and DCI-P3 P3 to
          either (consistently) dci-p3 or p3
      - color() fallback should be like font list fallback.
      - add a working-color-space at-rule, which affects the entire
  - The breakout session proposed resolving to publish WD for Color
      and MQ4.
  - RESOLVED: Do black point compensation when converting from
              profile to another.
  - RESOLVED: If you accurately describe the output device's color
              profile in an @color-profile rule then a sane
              implementation will not alter your colors so this is
              sufficient as a replacement for device-cmyk in general
              and provides a good RGB fallback automatically.


  - RESOLVED: Add allowing track list in repeat() and auto-rows
  - RESOLVED: Drop named lines specified on the subgrid
  - RESOLVED: Publish a new WD.


  - RESOLVED: Publish a new CR flexbox.


  - RESOLVED: Publish inline


Agenda: https://wiki.csswg.org/planning/san-francisco-2016#proposed-agenda-topics

*** Color Breakout Session Minutes ***

CSS Color

  Scribe: zcorpan

  <ChrisL> https://drafts.csswg.org/css-color/#lab-colors

  ChrisL: We've had discussion in the last f2f for things we've
          wanted to do.
  ChrisL: Apple have fancy screens now and want to take advantage of
  ChrisL: something something colorspaces.
  ChrisL: XYZ is a colorspace that can describe all known colors.
  ChrisL: XYZ fails to do white adaptation.
  ChrisL: LAB sticks an axis to the white point and if you take a
          perfect white surface, that's 100
  ChrisL: then two orthogonal channels A and B that correspond to
          greenish and yellowish axises.
  ChrisL: LAB is useful, you get it in physical measurement devices

  Florian: In the luminosity direction, how white is 100%?
  ChrisL: There are different standards for standard daylight and
          the one sRGB uses
  ChrisL: (before) LAB uses D50
  ChrisL: ... this is all just summarizing the spec.
  ChrisL: If you look in the spec, I've tried to keep the math to a

  ChrisL: issue about out of range numbers
  ChrisL: steps for how to convert ...
  TabAtkins: what is a reasonable range for C?
  ChrisL: to go from LAB to ???
  TabAtkins: so conversion between a/b and c/h is just rectangular
             to polar
  ChrisL: this is using the color() function, see example 9
  ChrisL: it's like @font-face
  ChrisL: you give it a url
  TabAtkins: idents is the right thing
  ChrisL: ident and then as many numbers as needed

  <dbaron> ACTION ChrisL to add note explaining a reasonable range
           for C in lch() to the spec
  <TabAtkins> https://drafts.csswg.org/css-color/#color-function
  <dholbert> (inside of https://drafts.csswg.org/css-color/#icc-colors )

  Florian: Why only 2?
  ChrisL: sRGB could be added but it doesn't give us anything new.
  ChrisL: Happy to add it if people want it.
  smfr: Makes sense for consistency.

  ChrisL: There's a section about grayscale.
  ChrisL: Consider replacing the grayscale section with a grayscale
  ChrisL: We had a briefer syntax.

  leaverou: What about thing like named color profiles ?
  leaverou: Spot colors.
  ChrisL: Does not allow overrange values.
  ChrisL: We've handwaved about this for a long time.
  ChrisL: There was a linear space that was easy.
  ChrisL: There's something black that's not absolute black.
  ChrisL: That lasted for 2 years and then they decided to use a
          wider gamut if you want a wider gamut.
  ChrisL: We should have early clipping.
  cabanier(?): It's quiet about that.

  smfr: Do we want commas?
  TabAtkins: No, because we want to allow alpha.
  TabAtkins: Need to distinguish.
  ChrisL: So no commas between numbers in examples.

  <dbaron> ACTION ChrisL remove commas between in the color()

  ChrisL: Next section is P3 and Rec 2020.
  ChrisL: These refs can be added to MQ4.

  <dbaron> ACTION ChrisL fix the currently-broken Rec.2020 reference
           in the spec

  leaverou: If one is supplied no color profile, it will be ignored?
  ChrisL: @color-profile foo icc profile which is treated differently.
  leaverou: This might be confusing in some cases.
  ChrisL: It will look wrong if you copy a color but not the profile.

  TabAtkins: Rec.2020 is not a valid ident.
  TabAtkins: Rec2020 works fine.
  ChrisL: Thank you, noted.
  TabAtkins: Also ascii as lowercase please.
  ChrisL: mkay
  TabAtkins: Match what MQ does.

  <dbaron> ACTION ChrisL fix Rec.2020 and Rec2020 to be rec2020, and
           DCI-P3 P3 to either (consistently) dci-p3 or p3

  ChrisL: Colors in wide color space and the device with a narrower
  ChrisL: What do you do with the ones outside?
  ChrisL: If it's an image with a nice gradient, things can look ugly.
  ChrisL: You move everything proportionally so that it looks nice
  ChrisL: but it's handwaving.
  ChrisL: Maintain the relationship between colors but they're all
          going to match.
  ChrisL: It's fine for a photograph but not when you want to match
          up a color in an image with a css color
  ChrisL: Saturated is useless.
  TabAtkins: Can we drop it?
  TabAtkins: Can we only allow them to choose the ones we care about?
  ChrisL: yeah... think so
  smfr: I don't know if we want to drop absolute color metric, might
        be useful for testing
  ChrisL: "this has to have an absolute luminance of this"

  Florian: If you have several profiles with the same color space?
  ChrisL: Last one wins.
  TabAtkins: They cascade as a unit

  cabanier: This is basically unused. Can we leave it as is?
  ChrisL: In svg2 you have to overwrite the profile.
  ChrisL: Should we remove the rendering intent thing?
  cabanier: Just use the default.
  TabAtkins: Need some way to choose the default.
  ChrisL: Perceptual is less good for css.

  smfr: Why is rendering intent tied to color profile?
  smfr: You want to specify rendering intent ...
  ChrisL: The way ICC profiles work, is you have a profile for your
          source data
  ChrisL: then you have a profile for your output device
  ChrisL: compose those two.
  ChrisL: How are you going to handle out of gamut colors?
  ChrisL: If you select perceptual
  ChrisL: it's less applicable to a wide gamut screen.
  ChrisL: An image has an intent built in;
  ChrisL: you can't override it.
  TabAtkins: If the profile has multiple intents you can specify the
             one you want.
  Florian: If the profile has multiple, does it specify the default?
  ChrisL: Yeah.
  cabanier: We set that as the default in the product.

  Florian: It's ok for photos and what we should use for the rest?
  ChrisL: Yes.
  ChrisL: Named color profiles, instead of having a mapping from a
  ChrisL: You have mapping from a name.
  ChrisL: People can do their own ones.
  ChrisL: This syntax does not cope with that but can be extended to
          do so.
  Florian: color() function, either a list of numbers or a string
  Florian: The other extension is to allow you to name your colors.
  Florian: New descriptor, @color-profile foo { src:...;
           named-color: "myblue" 00255, ...;
  Florian: Maybe not necessary because of variables.

  leaverou: Can you rename existing colors?
  ChrisL: Yes.
  TabAtkins: Don't object but it's strictly not necessary.
  ChrisL: I like it but variables is enough.
  cabanier: Print with specific ink...
  Florian: Can do that with this or with variables
  Florian: The variable contains "foo" 00255 so it contains the
           right colorspace.

  TabAtkins: Are these profiles text files?
  ChrisL: No terrible binary files.
  ChrisL: Tool to convert to xml so you can hack and convert back.
  dbaron: Some security vulnerabilities.

  esprehn: Apple have fixed security bugs in icc.
  ChrisL: Should restrict to same-origin.
  TabAtkins: Web policy, things should default to same-origin.

  ChrisL: Why are people using google fonts?
  TabAtkins: CORS, no problem
  smfr: Before you download you have to wait for ICC to download,
        like with fonts.
  smfr: Need to describe what should happen before it is downloaded.
  smfr: Would not impl except for built-in color profiles.
  esprehn: Same for us.
  Florian: context-dependent profile
  esprehn: Won't implement.
  Florian: What do you fallback to?
  esprehn: Wouldn't paint, same as fonts.
  Florian: So everything's white?
  ChrisL: Flash of uncalibrated color.
  esprehn: Yeah.

  esprehn: I'd like to see that you can specify a name so you don't
           need to download if you already have it.
  ChrisL: Fonts have local() for that.
  ChrisL: Fine to have that here also.
  ChrisL: How do you name your profiles, typically don't have a
          unique name.
  ChrisL: How do i define it?
  TabAtkins: Platforms can define what their names are and you can
             put it in the spec?
  ChrisL: So it's different per platform? -_-
  TabAtkins: Here's url, here's hash.
  esprehn: Not a security issue, privacy issue.
  TabAtkins: Fingerprinting is a lost cause
  dbaron: You can binary test for any font.
  TabAtkins: Fingerprinting is not fixable.

  leaverou: If I'm using super-RGB color space, makes sense to
            fallback to sRGB until it's loaded.
  TabAtkins: So fallback to a known name?
  dbaron: Is there a dictionary of downloadable profiles we can name?
  TabAtkins: We can inline them in the spec, they're small.
  Florian: Want to point to an image to use it's profile.
  ChrisL: We can put an appendix of common profiles.
  ChrisL: Print profiles are not small.

  TabAtkins: In Houdini we want these to be serializable.
  TabAtkins: Represent something in the string OM.
  TabAtkins: Here's the profile, it's 700 bytes of chars.
  TabAtkins: The color is considered invalid until the profile is
  esprehn: Not going to reparse.
  TabAtkins: hrm.
  TabAtkins: ok nevermind.

  ChrisL: If you have a font stack, how does it work when the
          primary is downloaded?
  esprehn: Recompute, not reparse
  TabAtkins: Fallback in color(); fallback is like font list.
  esprehn: That's implementable.
  TabAtkins: Must provide a fallback.
  ChrisL: I'm fine with that.
  leaverou: Want to be able to fallback to a different profile.
  TabAtkins: That's fine.
  TabAtkins: In the color profile rule you can have a list of
             fallback profile names.
  TabAtkins: Also in the color() function you can have a fallback

  cabanier: Have to always specify fallback? no optional, ok.
  Florian: Can you use rgba() in the fallback?
  TabAtkins: ya

  ChrisL: Open issue, blending happens in sRGB.
  ChrisL: Which will give you clipping problems.
  ChrisL: Also doing maths wrong.
  ChrisL: Was going to add linear.
  ChrisL: There's hardware support.
  ChrisL: You can get the right result with LAB.
  ChrisL: We need a thing that says how you composite things.
  smfr: Compositing and blending has a similar problem.
  cabanier: The gamut is being worked on in the canvas spec
  cabanier: need to specify, just 1.
  smfr: We can't change the default because that breaks web pages.

  TabAtkins: Subframes does it only work for top-most windows?
  TabAtkins: iframe
  Florian: If it doesn't say but the iframe does, does it propagate
  TabAtkins: No. You can have two iframes

  smfr: I can't find linear blending in the spec.
  ChrisL: It's an open issue.

  Florian: When you've done your things in your colorspace, when
           you've done it, what do you export it into?
  ChrisL: the output colorspace, whatever that is.
  ChrisL: LAB is convenient for this reason.
  Florian: If you use anything but LAB do you need to go through LAB
  ChrisL: Yeah.
  Florian: When that's specified, do the color math other than color
           blending also happen in that colorspace?
  Florian: If we have LAB, can I switch to it and use it for ???
  ChrisL: Yes but you get different result.
  Florian: Yeah, that's the point.
  cabanier: If you render in colorspace then all colors are in the
            same colorspace.
  ChrisL: I've seen examples of interpolation of ???

  ChrisL: Can we pick a placeholder name?
  TabAtkins: document-interpolation-color-space
  smfr: working-color-space?
  TabAtkins: yeah
  cabanier: You map your colors so it's fine.
  ChrisL: 3x3 matrix
  ChrisL: Don't use 8 bits.

  ACTION ChrisL working color space

  Florian: sRGB?
  ChrisL: Auto is sRGB
  ChrisL: linear-sRGB
  ChrisL: LAB
  ChrisL: Any others?
  cabanier: The list of working spaces can't include linear?
  ChrisL: Why not?
  cabanier: Can't implement it yet
  ChrisL: That's wrong. HW has it already
  ChrisL: Can do it in linear-sRGB with clipping
  cabanier: Need to change the blending spec.
  cabanier: So the output is bogus?
  ChrisL: No, it's wrong now but people are used to it.
  ChrisL: Yes you will get a different result, if you're not using
          linear space you're technically get the wrong result now.
  ChrisL: Additivity...
  ChrisL: Measure the light of two lights.
  ChrisL: Additivity means I can take the two numbers and get the
          right result.
  ChrisL: In linear space you get the right result with +, otherwise
  Florian: In LAB, linear matches perception, which is nice.
  ChrisL: Exactly.

  smfr: MQ?
  cabanier: Should match canvas.
  cabanier: ... p3 2020, optimal (matches the screen)
  cabanier: On iMac you would be compositing in p3.
  cabanier: The gamut most closely matches the output.
  ChrisL: ok so MQ.

  Florian: I think what's in the spec now which is TabAtkins's
           interpretation of what we had in the mailing list, is
           fine with me.
  Florian: If people disagree say where and why.
  dbaron: This is a new type of MQ.
  dbaron: MQ where more than one of the values can be true.
  TabAtkins: Yeah all the range based ones have that.
  dbaron: It's a set MQ rather than a discreet MQ.
  dbaron: Might want to describe as a different type.
  TabAtkins: ok

  ChrisL: Are they ordered?
  TabAtkins: Only range features have an ordering.
  Florian: That you can do "less than".
  dbaron: Color gamut sRGB means it can do all of sRGB
  TabAtkins: Should we add a value for "narrow" for extra-low gamut
             (below sRGB)?
  dbaron: Concerned whether we CAN calculate it, if we have
          information to calculate it.
  Florian: Should I load normal images, fancy images or super-fancy
  leaverou: Percentages seems useful.
  smfr: No this is good enough.
  TabAtkins: Boolean context are true for anything other than none
             or 0
  TabAtkins: Not (boolean) is true.
  smfr: You're asking about the OS, not the screen.
  TabAtkins: It does not talk about the output device, need to fix

  Rossen: Present to projector.
  Florian: Two screens?
  esprehn: Every monitor has its own profile, if you move a window
           between two, we repaint the window, which resolves the
           colors again.
  Florian: The incentive for UAs to lie is not high, it only makes
           you download heavier images than you need.
  TabAtkins: If there are multiple screens...
  Florian: Why not the highest?
  TabAtkins: In general you want the lowest.
  TabAtkins: Want to see the same thing as what's on the projector
  TabAtkins: below CSS.
  Florian: There are objections that this is not restricted to RGB
           spaces or the screen media type.
  Florian: If you have a whatever colorspace, if it's bigger then p3
           then you match.
  Florian: People have disagreed with that.
  Florian: Maybe add a cmyk.
  ChrisL: We have TVs which have ???
  Florian: if you have a sucky printer sRGB is what you get.
  TabAtkins: We can add specific named variants.
  Florian: For UAs that don't output in cmyk, this has 0 impl cost.
  TabAtkins: We dismiss the objections and go with the current design.
  Florian: Happy with that.

  ChrisL: Publish this?
  TabAtkins: Intent to publish.
  PROPOSED RESOLUTION: publish css-color and mq4
  dbaron: There's impl interest for some things but not others.
  dbaron: Might be worth trying to figure that out sooner rather
          than later.
  TabAtkins: Figure out what we want to impl.

  ChrisL: color-mod() problems TabAtkins?
  <smfr> https://drafts.csswg.org/css-color/#modifying-colors
  TabAtkins: 1) syntax is confusing and crappy
  TabAtkins: I agree partially
  TabAtkins: it's overcomplicated.
  esprehn: Aliasing for everything? can we not do that?

  TabAtkins: 2) ??? is not super useful for real-world stuff
  TabAtkins: Modifying one color...suggested some different
             operations that I want to put in here instead.
  TabAtkins: Replace this with something like blending two colors
  leaverou: Lightness or mix with white and black which works better.
  TabAtkins: Color blending, color contrast, tint and shade.
  leaverou: I implemented a polyfill, it occurred to me that there
            were lots of (((()))) like lisp.
  TabAtkins: The grammar is intended to reduce that.
  leaverou: I suggest keywords.
  TabAtkins: I agree.
  leaverou: Crazy idea, what if we can use calc(color +
            semi-transparent white) then it blends with alpha
  TabAtkins: calc is for numerical things.
  TabAtkins: We have cross-fade as existence proof that we use a new
             function for specific things.
  TabAtkins: We need color blending for convenience and so you can

  Florian: device-cmyk
  ChrisL: If you have calibrated device-cmyk.
  Florian: That's no problem.
  ChrisL: If you don't provide a fallback you get a bad color.
  Florian: How does it work?
  ChrisL: It means here are some numbers, don't mess with them at all.
  Florian: If we composite and alpha-blend ....
  ChrisL: If you use color() to do that, it looks better.
  ChrisL: Inks are not transparent, can't overlay them.
  ChrisL: Have a pattern of dots instead in a grid.
  ChrisL: Overlaid in different angles.
  ChrisL: If you have a pale yellow and then few dots of black.
  ChrisL: That's what device-cmyk is for.
  ChrisL: Don't want those black dots.

  Florian: Why does output to PDF file have anything to do with the
  TabAtkins: Don't have at a distance logic in MQ
  Florian: If you're a headless device?
  Florian: OS doesn't know what to do.
  Florian: What does the MQ do?
  ChrisL: It should say yes to everything, can print to pdf in any
  leaverou: Can we get rid of device-cmyk somehow?
  TabAtkins: It's implemented.

  ChrisL: Black point compensation.
  ChrisL: White is easy.
  ChrisL: TVs can get much darker black.
  TabAtkins: Can we not do something like white compensation?
  ChrisL: No. the spec says why.
  ChrisL: Same mutual axis.
  ChrisL: It's not pegged at 0 it's pegged at some dark.
  ChrisL: Certain amount at the bottom for deeper blacks.
  ChrisL: Do need to cope with that.
  ChrisL: Wording about rendering intents.
  ChrisL: Black point compensation matches or not.
  ChrisL: With or without black compensation.
  ChrisL: In PS it will ask if you want black compensation.
  TabAtkins: Which do we want?
  cabanier: Turn it on.
  TabAtkins: ok. Done?
  cabanier: Color conversion engine can do it for you.
  cabanier: Same thing happens with whites.
  cabanier: White stays white.

  RESOLVED: Do black point compensation when converting from profile
            to another.

  smfr: For print also?
  ChrisL: Yeah.
  ChrisL: Doesn't affect p3, does affect 2020.
  TabAtkins: Can I reformat everything?
  ChrisL: Sure.

  Florian: The only thing we haven't agreed on is the working color
  ChrisL: Right.

  leaverou: device-cmyk
  leaverou: Stylesheet was used for printing to ebook.
  leaverou: Using something similar to device-cmyk.
  leaverou: One problem is that you specify a device-cmyk color but
            you want...
  leaverou: it would be nice to specify which profile to use.
  TabAtkins: Use the color() function and the cmyk profile?
  leaverou: Want to use device-cmyk for print.
  TabAtkins: What's wrong with just defining the cmyk profile in
             color() instead of device-cmyk?
  leaverou: I thought we decided to keep device-cmyk?
  TabAtkins: Will fix by having a decent list of predefined
             profiles, one of those can be device-cmyk.
  TabAtkins: Falling back to something you have defined.
  ChrisL: Seems backwards.
  TabAtkins: If you have a correct profile for your output device...

  dbaron: Is the assumption is that only print uses device-cmyk?
  leaverou: Never want it for screen.
  leaverou: Not just about PDF.
  dbaron: Do you want a magic profile name for device-cmyk vs other.
  leaverou: Want to specify colors once.
  ChrisL: Want to see results from impl.
  Florian: The printer has everything it needs to do it right.
  TabAtkins: Use color(cmyk) will be good.
  leaverou: ok that works.
  TabAtkins: Get a good conversion instead of a naive.

  RESOLVED: If you accurately describe the output device's color
            profile in an @color-profile rule then a sane
            implementation will not alter your colors so this is
            sufficient as a replacement for device-cmyk in general
            and provides a good RGB fallback automatically.

  TabAtkins: We can deprecate device-cmyk.

*** Return to regular meeting minutes ***

Summary of breakout sessions
  Scribe: fantasai

  TabAtkins: Chris went over new features adding to color.
  TabAtkins: General agreement on all of them.
  TabAtkins: In particular lab() and clb() [mistyped].
  TabAtkins: And new color() function.
  TabAtkins: Refers to arbitrary color profile.
  TabAtkins: Give it whatever parameters it expects.
  TabAtkins: Paired with that is @color-profile rule, which lets you
             refer to color profiles by URLs.
  TabAtkins: Will have a handful of predefined ones.
  TabAtkins: Since a lot of color profiles are quite small.
  TabAtkins: Decided to be liberal in predefining common Mac and
             Windows profiles.
  TabAtkins: For less URLs.
  TabAtkins: Wanted to make some changes around fallback.
  TabAtkins: And adding fallback things to color profiles.

  myles: What does UA do before downloading profile?
  ChrisL: Uses a fallback color.
  TabAtkins: We have 2 levels fallback.
  TabAtkins: @color-profile can list fallback profiles.
  TabAtkins: E.g. refer to AdobeSRGB, and fallback to regular sRGB.
  TabAtkins: Can also fallback explicitly for specific colors.
  Florian: If you did neither, it's invisible, becomes invisible.

  TabAtkins: Also discussed color-mod function.
  TabAtkins: Agreed to kill it in general, and then respec color
             blending / tint / and shade functions.
  TabAtkins: Because those are useful/simple that are highly
             requested by authors.

  fantasai: Did you talk about making a cut for Level 4 that's just
            the really basic simple things?
  TabAtkins: Did, plan to publish a new WD first to get an update,
             then make a cut.
  ChrisL: There was a lot of wording about rendering intent, decided
          not to do, but since we had the wording, better to publish
          with that wording and then remove it in the next
  TabAtkins: At the end, casually decided to drop/punt APIs for
             parsing/manimpulating colors.
  TabAtkins: Going to explore in Houdini, if necessary.
  TabAtkins: This isn't the right spec for it.

  Florian: Also went through media queries, found spec as is to be
  TabAtkins: Wanted to make a clarification.
  TabAtkins: but agreed on resolution.
  Florian: Editorial.
  TabAtkins: I believe that's it.

  Florian: One thing we couldn't agree on.
  TabAtkins: Wanted to define a working color space for compositing.
  TabAtkins: But we couldn't agree on doing it right now because
             it's very expensive to composite.
  Florian: Could agree on the syntax for this, but not on the list
           of color spaces to allow.
  Florian: Some are expensive but good, others are cheap but wrong,
           others are not well-understood by people at the table at
           the moment.

  TabAtkins: Hallway conversation with Elliott, opacity is misplaced
             in this spec, better moved into either Filters or
             Compositing spec.
  ChrisL: Yes.
  leaverou: Yes.
  ChrisL: But also have alpha values.
  <bradk> waaaa?
  TabAtkins: Can just move it to V&U.
  Everybody: What?
  ChrisL: Putting in Compositing seems to make sense.
  TabAtkins: <alpha> being <number> | <percentage> where number 0..1

  [fantasai summarizes resolutions from scroll-snap breakout]

  Scribes: gregwhitworth & tantek

  TabAtkins: First issue is the repeating syntax.
  TabAtkins: The grid auto rows only allow you to set one track worth.
  TabAtkins: Once you have subgrid you want to repeat on more than
             one track.
  TabAtkins: So the repeat will take a track list.
  TabAtkins: Auto is required, but maybe the repeat function should
             be changed.
  TabAtkins: Auto is actually required because you can't control the
             implicit grid.
  TabAtkins: Now that we have a reason to add back multi-track
             repetition into the repeat() function but subgrid
             brings that back.
  fantasai: Not for auto fill.
  fantasai: Subgrid is a compelling use-case (we didn't have one
  TabAtkins: It just repeats whole tracks, when you're dropping
             tracks from fill you drop whole tracklists.
  dholbert: These are two distinct changes.
  fantasai: Yes.

  astearns: Any objections?
  Rossen: We'll bring issues when we get more implementation
          experience, for now it seems reasonable.
  <tantek> When you're dropping tracks from fill, you drop whole
           repetitions etc.
  astearns: Any objection to adding multitrack repetition to
            accommodate subgrid use-cases?
  Rossen: We'll bring issues with more implementation experience.

  astreans: RESOLVED: add in multitrack repetition to accommodative
            subgrid use-case
  RESOLVED: Add allowing track list in repeat() and auto-rows

  fantasai: We prefer to just drop named lines specified on the
            subgrid because grid-template does not apply to
            simplified subgrid.
  fantasai: We are referring to dropping name lines specified on the
  fantasai: Via grid-template-columns.
  fantasai: Via the old subgrid you could do that.
  fantasai: We're proposing to drop because it adds syntactic
  fantasai: Possibly can apply in the future in interesting ways.
  fantasai: Since we're not tackling that now, let's just remove
            that now.

  TabAtkins: Any objections?
  TabAtkins: Does anybody still want the ability to declare new
             named lines on subgrids?
  plinss: You can't create lines in a subgrid
  astearns: Seems fine to drop.

  RESOLVED: Drop named lines specified on the subgrid

  fantasai: Can we publish a new WD?

  RESOLVED: publish a new WD


  fantasai: One more thing, update flexbox CR
  fantasai: we would like to update the CR with the issues
  astearns: Any objections to publishing with edits?
  fantasai: We're asking for people to setup the relative telecons
            and do the whatever whatevers
  fantasai: Resolution to take to CR once we generate a new draft,
            and action chairs/staff to setup relevant telcons.
  TabAtkins: I expect next week to finish bikeshed integration for
  TabAtkins: and I expect to finish up the something akin
             integration for pushbutton CR.

  Rossen: Have resolution now?
  fantasai: The disposition of comments is complete.
  TabAtkins: Flexbox CR draft is done and ready.
  astearns: Any objections to doing a new CR for flexbox?
  <fantasai> https://drafts.csswg.org/css-flexbox-1/issues-cr-20160301
  astearns: strategy, call for publications at the end of long days
  dbaron: lol

  RESOLVED Publish a new CR flexbox.

  dbaron: And try not to break the 86 day record for slowness.


  fantasai: CSS inline has had a few small changes from various F2Fs.
  fantasai: Since we're publishing stuff maybe we should publish and
            update to the inline spec.
  fantasai: Proposed publishing new draft of CSS inline.
  astearns: I'm sorry is this the fourth one more thing.
  <tantek> +1
  <dauwhe> +1
  astearns: I'm happy to, any objections?

  RESOLVED: Publish inline

  gregwhitworth: Done for the day - Thank you Google for hosting
Received on Tuesday, 7 June 2016 18:26:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:03 UTC