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
          spec
      - 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
          document
  - 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.

Grid
----

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

Flexbox
-------

  - RESOLVED: Publish a new CR flexbox.

Inline
------

  - RESOLVED: Publish inline

===== FULL MINUTES BELOW ======

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
          that
  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
          etc.

  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
           minimum.

  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
          colorspace.
  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()
           examples

  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
          space.
  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
          number.
  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
             downloaded.
  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
             color.

  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
           up?
  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
           first?
  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
          not.
  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
           images
  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
             wording.

  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
             together.
  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
            blending?
  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
           screen?
  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
          profile.
  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
           profile?
  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
          publication.
  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
           adequate.
  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]

Grid
----
  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
            before).
  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
            subgrid.
  fantasai: Via grid-template-columns.
  fantasai: Via the old subgrid you could do that.
  fantasai: We're proposing to drop because it adds syntactic
            complexity.
  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

Flexbox
-------

  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
             echidna
  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.

Inline
------

  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
                 us!!!!!!
Received on Tuesday, 7 June 2016 18:26:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 7 June 2016 18:26:38 UTC