W3C home > Mailing lists > Public > www-style@w3.org > September 2015

[CSSWG] Minutes Paris F2F 2015-08-26 Part I: Round Display, Grid Layout [css-round-display] [css-grid]

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 11 Sep 2015 14:32:00 -0400
Message-ID: <CADhPm3t4VHnAmp+vP3AFH70cO7EOgnQJqTgkGJgge2R6KQ=3rw@mail.gmail.com>
To: www-style@w3.org
Round Display

  - The representatives from LG presented their work on round
      display, including several demos of test cases.
  - The group thought the progress was good and the use cases
      compelling, though there was in expressed desire to have the
      spec written to apply more widely instead of focusing only on
      round displays.
  - Some pieces of the spec may ultimately belong in other existing
      specs, but for now they will be worked on here until they
  - There were several issues to resolve, some editorial and some
  - RESOLVED: Pending notation of any open issues in the draft,
              publish FPWD of CSS Round Display
  - RESOLVED: Add Hyojin as an editor to round display, move Soonbo
              Han to former editor

Grid Layout

  - RESOLVED: switch row-gap/column-gap to grid-column-gap and
      grid-row-gap and maintain grid-gap as the shorthand name.
      - It is possible that they will be named grid-gap-rows
          grid-gap-columns instead depending on the results of
  - RESOLVED: stretch stretches auto-sized tracks only
  - RESOLVED: Add repeat(auto-fill) and repeat(auto-fit)
  - RESOLVED: Publish grid WD after the above edits


  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Brian Birtles
  Bert Bos
  Tantek Çelik
  Dave Cramer
  John Daggett(phone)
  Elika Etemad
  Jihye Hong
  Dael Jackson
  Dean Jackson
  Ian Kilpatrick
  Chris Lilley
  Peter Linss
  Edward O'Connor
  Simon Pieters
  Liam Quin
  Matt Rakow
  Florian Rivoal
  Andrey Rybka
  Hiroshi Sakakibara
  Simon Sapin
  Hyojin Song
  Elliott Sprehn
  Alan Stearns
  Shane Stephens
  Lea Verou
  Sam Weinig
  Greg Whitworth
  Johannes Wilm
  Steve Zilles

  Daniel Glazman
  Anton Prowse

  agenda: https://wiki.csswg.org/planning/paris-2015#agenda
  scribe: dael

Round Display

  plinss: Let's get started
  <hyojin> CSS Round Display - Demo, Issues, FPWD Spec:
  <hyojin> Polyfill:
  hyojin: I'm Hyojin Song and this is CSS Round Display.
  hyojin: There are several interested parties. We use Web OS, so
          all applications running on the device are web apps.
  hyojin: We believe that round display will be generally useful
  <astearns> new properties are device-radius, shape-inside,
             border-boundary, and polar

  <Bert> -> https://crosswalk-project.org/ Crosswalk Project

  Joone: I work with Chromium Dev.
  Joone: During the last couple months we have been implementing
         round display. It's based on chromium and allows developers
         to work with web technology. The web API and native
         intention fills the gap between web and native.
  Joone: We support round display to allow developers to support
         round across platforms including watch devices. Round
         display would let them support watch devices with web tech.
  Joone: Also, being able to surf the web with watches may become
         common in the future. People spend more time browsing the
         web on mobile devices.

  Joone: We implemented device-radius with a boundary and there were
         issues. It only provides information on if the screen is
         round, there is not more detail such as the device-radius
         in the spec. There was no way to know the radius, I think
         there should be more information on this including the
  Joone: The other issue is border boundary. When you surf you may
         get a scrolling border. I think the web engine should not
         code web pages so the border boundary is supported. Jihye
         will show a demo.

  <fantasai> The first example showed a weather app, with a blue sky
             background and a white band containing information
             about the weather.
  <fantasai> In square displays the white band was a box, smaller
             than the width of the screen, floating over the blue sky.
             Additional UI elements are positioned in the top corners.
  <fantasai> In the round display UI elements in the top corners
             were moved to the center, and the box was turned into a
             band across 2/3 of the screen.
  Jihye: We made a simple web app with a device using round
         properties. As you can see in round display the alignment
         of elements is specified to the round display.
  Jihye: It is possible because the app recognizes the shape of the
         device. Without the device properties and when we implement
         only considering the web and rectangular devices, some part
         of the display will be concealed from round display.
  Jihye: This example shows how the property works. The border is
         painted around the edge of devices.

  Jihye: I will show some example using Garnet.
  <fantasai> The example showed a round timepicker with a digital
             clock across the top third of the screen, X and check
             buttons across the bottom third, and hour/minute
             numbers around the clock face.
  Jihye: This example shows the sample of garnet the web app
         framework that is used in other digiwatch which is using
         web OS platform. With this example you can choose the time
         from the number elements located around the round display.
  Jihye: Not only in these examples, there are so many use cases in
         which elements are laid out like this one. Developers have
         to consider the center points and radius of the display as
         well as a radial variable.
  Jihye: Described using our method, the elements can be located
         easily using polar position, angle, and distance.

  <fantasai> This example is showing a scroll list, with each item
             having an image on the lefthand, title and description
             on the right.
  <fantasai> There's a title at the top, which is sticky
  <fantasai> The scrollbar is wrapped from the top of the circle to
             the bottom, with a curved scroll tab
  Jihye: This is another example to show the scrolling event in
         round display. Different from the normal scrolling amounts,
         this UI is similar to scroll event.
  Jihye: When I'm using this, the scrolling is more comfortable and
         faster than the normal method in the round display. In the
         sample, coordinates are complicated. When the rounded
         method is implemented in real devices, scrolling
         performance is lagging. When we use polar distance and
         angle you can get improvements in showing the scrolling and
  Jihye: From the example just shown, I can show the properties
         related with polar, but the scrolling on the display isn't
         so different from general devices.

  Jihye: I found this YouTube video about scrolling events in round
         display. Elements are arranged constantly in round method.
  <skk> This might be the demo video:
  <skk> https://www.youtube.com/watch?v=PRWHJwHqHuM
  Jihye: When developers want to do layout like this they have to
         use CSS shape and the text elements located are calc in
         real time. We are planning to expand round display to deal
         with the scrolling event.

  hyojin: That's the demo, the key point is it gives us radius and
          boundary as a prototype. We think those things are useful
          for authors.
  hyojin: Next, I will check the status of round display now. It
          could be bigger. We implemented the pictures. Would you
          show the spec for round display?
  <astearns> https://drafts.csswg.org/css-round-display/#device-radius-media-feature
  hyojin: In terms of status, we would like to take round display
          to FPWD
  hyojin: Round display is used to make this seem very simple. We
          would like a FPWD. I think to express the device display
          sheet would be of use.

  hyojin: Any other opinion about device-radius?
  Florian: I think the general idea is about right. We could think
           of very complicated MQ to be explicit, but overshooting
           wouldn't be a good way of solving this. The level of
           complexity you're exposing is approximately right. I
           think there is a need for more details in the spec. It
           doesn't say if the corner is an elliptic or cut corner.
  Florian: I think the MQ as described now could work, it just needs
           more details in the spec. I think we should try to flesh
           it out. I think the device radius MQ is generally the
           right approach.
  Florian: It will work for elliptic displays if it uses device
           radius instead of pixels. For cut corner, that's not the
           goal of this, but we should be able to give some
           reasonable semantics if the corner cuts less than the
           rounded corner. We can use min and max to get that.
  Florian: If we spec these details correctly, we can do that.
  hyojin: We received comments from Florian about the device radius.
          We should cover the remaining issues in device radius.

  Florian: Has anybody else thought of a different way of fixing
           this, or does this sound right?
  gregwhitworth: I tried writing a response, but we're not in the
                 market. My response was that this is perfect for
                 the round display spec, but what if I want to do
                 polar distance on something that's not round. I'd
                 like to see it generalized. All the pieces are
                 necessary to accomplish this task. Just in general
                 generalize the pieces so that they can accomplish
                 more, make them generic. That gives you more power
                 down the road.
  gregwhitworth: Definitely you're providing a good use case as you
                 showed in the demo. Such as polar distance, you can
                 use any shape. You can calc the center of any shape.
  Florian: The details we need to look into, but I think it can work.
           If you define 100% is the edge against the edge, if
           you're 100% you're following the shape. There's details,
           but we can work out the general.

  fantasai: Should we pull the device radius MQ into the MQ spec?
  Florian: I'm fine either way. I suggested it last time, but there
           was a thought to keep the pieces together. It's a
           question of who is working on it.
  fantasai: I think we should eventually.
  gregwhitworth: I think for all of them, position polar is a great
                 way of fleshing this out, well done. I think we
                 should be able to use it in a positioning spec,
                 though. I'd love to see them focus on not just the
                 use case of watches. Something more generic.
  liam: gregwhitworth I think you made a good point because I think
        we're going to find other shapes in the future. I think
        there's a danger of trying to solve too general a case.

border-boundary/shape-inside: display

  fantasai: For the border-boundary and shape-inside: display
            values, what happens when you have these in an element
            that scrolls?
  hyojin: Scroll is difficult. We internally tested significantly to
          use shape-inside. We had some differences to describe
          scroll in shape-inside.
  Florian: The scrolling problem isn't limited to shape-inside:
  fantasai: But what happens if you just scroll the outer document
            and the position of the element changes?
  TabAtkins: The way my watch does it is while you are wrapping to
             the shape you can't scroll. If you tap you can scroll
             and it turns into a rectangle shape.
  TabAtkins: The idea I guess would be it maintains its shape based
             on your initial scroll position? So if you do scroll
             the doc you'd get a weird circular area moving up.
  Bert: I see in the spec it creates an intersection of the circular
        area so the shape changes as you scroll.
  Florian: The text was re-wrapping as you scroll.
  astearns: The content stayed with the same line breaks and it
            moved with the shape.
  plinss: I'm not sure the demo is complicated enough to show that.

  TabAtkins: I'm reviewing the video and it's using padding.
  gregwhitworth: They had something where the contact list was
  TabAtkins: That was something magic and random.
  gregwhitworth: You can see it's not wrapping on the video.
  TabAtkins: That's a custom scroller.
  astearns: It's probably wrapping to the widest point in the
            display and moving around. There's other scrolling
            strategies for rounded shapes. If you have the content
            laid out for three items and you flick to scroll you can
            scroll the entire thing away and get new items.
  Florian: And there's a number of similar UIs to pagination.
  astearns: That was one of the strategies we considered when we did

  fantasai: Would it make sense instead of having a switch that makes
            individual elements match to the intersection of their
            area and the watch face area, to be able to say this
            element should have the same shape as the display, and
            also to saythat an inner element matches its containing
            block? Thenyou can have multiple divs the same shape as
            the displayin the same document, and within those you
            can instructthe contents to fit into that boundary (or
  astearns: Difference is knowing if the items inside will fit in a
            readable size.
  fantasai: That's what regions are for.
  liam: It breaks the metaphor that you're moving, though. There's
        quite a user issue.
  Florian: In the spec for border-boundary there is a value to match
           the display and to match the parent. We'll need something
           similar for the shape itself.
  astearns: Border-boundary has the parent value? It probably makes
            sense for shape-inside to have it too.
  TabAtkins: Do we have examples of border-boundary?
  Florian: In the weather app example there was a faint border and
           in the rectangular one there was border around the pieces
           of text.
  [The example is pulled up again]
  Florian: See the thin line around, that's a border boundary
           matched to a display.
  Florian: If you know the screen is round you can use border
           radius, but if you don't know that the screen is going to
           be round fitting to the display is what you're trying to

  esprehn: The demo text seems to be carefully selected to fit.
           Does text wrap at the edges?
  Florian: That's the shape-inside part.
  esprehn: In the blue box, if there was more text, does it wrap to
           the round edge?
  Florian: Yes.
  Bert: There's note in the border part saying the text may overlap
        the border or the other way around.
  TabAtkins: We know shape inside works with heavy overflow.
  hyojin: We can find use cases. We have some trouble to describe
          specifically. How can we do what it is?


  Florian: I think we need to go issue by issue. Doing a review of
           the entire spec in one go is something people won't have
           time to. I think we need to find one issue, fix it, and
           move to the next one. And we'll get there.
  gregwhitworth: He did ask for a WD, though.
  fantasai: If we're working on it, we should note the issues and
  Florian: Is there any new issues you might want to add?
  hyojin: We were planning to do scrolling, but we couldn't do that
          for now. These ideas are enough to be a FPWD.
  Florian: As we mentioned yesterday, it's good to have the entire
           scope of the spec ready of intellectual property reasons.
           If you want to add one more thing we should add it before
           going to FPWD.
  hyojin: It's okay to cover the whole idea.
  Florian: If you're happy to go with this the content is
  Bert: There will be other opportunities to mention things. The
        intellectual property will be gone over again with CR.
  Florian: The time in between would be long.

  hyojin: Would it be possible to do the WD?
  dbaron: I think it would be good to get issues noted in the draft.
  hyojin: The issues from last time, we modified the spec. We can
          get all these things, but we think it's enough to
  Florian: We don't have to resolve everything, just writing in the
           spec there is an issue when we don't have the solution is
  hyojin: We can do that.

  RESOLVED: Pending notation of any open issues in the draft,
            publish FPWD of CSS Round Display

border-boundary/shape-inside: display (cont.)

  Bert: Are we continuing this, or are we discussing more?
  Bert: I have 2 or 3 more details.
  Bert: About shape-inside, I was wondering if another definition
        might be useful. The shape-inside: display results in a
        shape that is the overlap of the actual viewport is the
        currenttext. What if I want to use that shape not on screen
        and move it in?
  Bert: So I want to make an element with that shape elsewhere and I
        want to move it in, not overlapping with the actual position
        of viewport.
  Florian: That would relate to the scrolling question earlier. You
           have to be careful to align when you do that.
  Bert: So reusing the shape, but independent of its position.

  plinss: How do you compute the intersection?
  Florian: You just do the same shape, you don't intersect. Just the
           same round of the screen.
  plinss: But if it's not the same shape?
  Florian: Same shape and size. That's tricky. If you have a square
           and a circle that fits, that's fine, but if you have a
           rectangle the same circle could fit, but there's a
  Bert: I could set top and left to 0 and it would align.
  Bert: That was my first thought when I saw the overlap.

Polar Positioning

  <dbaron> I think the polar positioning parts are quite
           underspecified, and I also don't understand why
           position:polar goes on the parent of the element being
           positioned -- but I thought we discussed that last time
           we discussed this spec.

  Bert: Polar position. I think gregwhitworth mentioned it also.
        This might be useful independent of fixed positioning. You
        might have any object and just add some angular position to
        that. That made me think the polar keyword shouldn't be on
        the position property.
  Bert: Should it maybe be somewhere so I can have abspos or
        relatively positioned that use polar.
  Florian: So you want a relative polar that's relative to whatever.
  Bert: So I set a relative position and I use polar to move it.
        Maybe just make the polar coordinate property active all the
        time, they're just 0 by default.
  <MaRakow> +1 to that
  plinss: So left is 50px and polar is 30 deg.

  Bert: That leads me to #3, we have a property for motion path
        which solves that.
  Bert: You would have the same effect with angular coordinates.

  Florian: To answer plinss's previous comment, you do positioning
           ignoring polar and from there you move in a polar way.
  plinss: So transform.
  Florian: Basically, yeah.

  Bert: I think motion path and angular can move in the same way.
  Florian: If the motion path is not a circle?
  Bert: Rounded corners, I don't know if there's a motion path.
  Florian: I think we can do this to follow the edge without even
           knowing what the shape is.
  Florian: If you go into a jewelry store there are varied watch
  Bert: I was trying to avoid redundant properties, but alright.

  Bert: Have you looked at transform and motion path for different
        way to do it?
  <Bert> http://www.w3.org/TR/motion-1/#propdef-motion-path
  fantasai: Note that motion-path has nothing to do with moving
  Bert: It's a way of translating an object.

  dbaron: So Bert was suggesting the polar stuff be relative to
          where ever it was. That seems to introduce more work for
          the author because they need to center it first and then
          move. Starting in the center is more useful.
  Bert: Using position fixed, that would default.
  dbaron: No, you wouldn't get that.
  dbaron: It would be good to have an issue before you publish.

  plinss: The percentage value on polar angle doesn't make sense. So
          50% is 180deg, yeah?
  TabAtkins: Polar angle is wrong.
  fantasai: It also puts lengths for angles. There's some copy/paste
  fantasai: There's no angle value for the polar angle.

  fantasai: Did that make sense?
  hyojin: Yes.
  gregwhitworth: Do we want to action the issue before FPWD?
  Florian: The issues are in the minutes.
  fantasai: It would be easier to find.

  <fantasai> ACTION hyojin Fix Value line of polar-angle propdef
  <trackbot> Created ACTION-706
  <fantasai> ACTION hyojin Fix Percentages line of polar-angle
  <trackbot> Created ACTION-707
  <fantasai> ACTION hyojin Remove "For" line from polar-angle propdef
  <trackbot> Created ACTION-708
  <fantasai> ACTION hyojin Make polar-angle animatable as an angle
  <trackbot> Created ACTION-709
  <fantasai> ACTION hyojin Make polar-distance animatable as an angle
  <trackbot> Created ACTION-710
  <Florian> ACTION hyojin to make position polar apply to the
            element rather than the parent
  <trackbot> Created ACTION-711
  <fantasai> ACTION hyojin Make polar-distance percentages relative
             to distance from center to edge of containing block (or
             mark this as an issue) so that it works for non-
             circular shapes as well
  <trackbot> Created ACTION-712
  <fantasai> ACTION hyojin Remove "for" line from polar-distance
  <trackbot> Created ACTION-713

  MaRakow: For figure 6, it seems to show it describing the center
           area when you're doing position polar, is that something
           that happens when you're using position polar?
  TabAtkins: I think it's how position polar works, seems reasonable.
  MaRakow: It would be good to specify.
  TabAtkins: It would mean polar distance of 0 would be in the
  Bert: And fantasai mentioned that 100% put it against the edge,
        not over.
  TabAtkins: Unless you're perfectly circular, though...
  Florian: I think we can spec it property, but it's impossible in
           real world geometry to get it always right. But at least
           when there is a correct, let's go there.
  TabAtkins: The whole concept only works when you're perfectly
             circular. If it's an ellipse, you don't want to move it
             all the way to the side when you have this huge major
  TabAtkins: The purpose of this is buttons and you know the height
             because it's an image.
  plinss: I accept that's common, but I don't think that's always
  Florian: You had the case before where it's not.

  TabAtkins: It's too magical to have something hug the edge. If
             you're rectangular, what do you do?
  Florian: You do it so the outer border is a tangent to the edge.
           If it's round you poke the corner at the edge.
  fantasai: It may not want to be default, but as an author it
            should be able to do it.
  plinss: There should be a way, and maybe there should be a new
          keyword. If 100% does it with magic, that's scary. If you
          have a rectangle you're moving in a circle, as I move it
          around the center if I'm 10% off it'll be moving in this
          odd flower shape. It should be achievable without
          JavaScript, but it shouldn't be the default.
  fantasai: That makes sense.

  Florian: In general I think for when designing layout and
           positioning, being robust to changes in the size and
           shape of display is something we try to do. I also accept
           plinss's point, so we need both.
  TabAtkins: I'm okay with more complicated requiring JS to run.
  TabAtkins: You're doing something that's fairly difficult. There's
             no flow, it's just abspos. That's in general a fragile
             method. If you want complexity you need JS.
  Florian: Abspos is fragile about some things, but 0 is the edge.
           It's easier for abspos, but you don't go off screen by
           accident if you do 0.

  fantasai: You could have a property that says where the anchor
            point is. Instead of always the center, choose which
            point and have an auto that picks it the point like
            bgposition does.
  gregwhitworth: This sounds like motion path again. You get to pick
                 you anchor points and the default is in the center.
  fantasai: You could have a polar-anchor. It would take a <position>
            and an auto keyword which would do the thing you want.
            In the cases where you want to position something
            exactly this distance you pick the bottom left corner.
  gregwhitworth: And the bounding box is a rectangle?
  TabAtkins: Border-radius is.

  tantek: Does anyone else have experience designing UI with polar
  Florian: liam had rounded pages?
  liam: Never with polar coordinates.
  liam: It is worth thinking about if you start dealing with polar
        coordinates, if you need trig in calc.
  Florian: Then you have to understand trig to use CSS.
  liam: You have to in order to use polar coordinates.
  liam: You work with non-rectangular if you do print work, but the
        page doesn't scroll so you can fake it with a shape on the

  hyojin: Soonbo Han is no longer working on this, so I would like
          to become the editor.
  hyojin: Would it be possible to change?
  Florian: If the person who was working on this no longer is, that
           makes sense.
  TabAtkins: That should be fine.

  fantasai: So, mark as an issue, potentially add an anchor property.
  fantasai: Is that a reasonable issue?
  Florian: Sounds reasonable to me.

  <fantasai> ACTION hyojin Add issue about positioning items to the
             edge of the containing block without overflowing it;
             potentially solved by polar-anchor: <position> | auto
  <trackbot> Created ACTION-714

  RESOLVED: Add hyojin as an editor to round display, move Soonbo
            Han to former editor

  fantasai: The top item should go to MQ, shape inside goes to
            shapes, polar coordinates into positioning. Border
            contain into borders 4. borders 4 is shaky right now.
            Positioning needs a lot of work.
  Florian: MQ is getting stable. There's a few area that are not
           quite there.
  fantasai: AS MQ approaches CR, we should pull in device-radius.
  Florian: Keep it together for now, pull out as these other specs
  plinss: Ready to move on?

Grid Layout

grid-gap-row vs column-gap

  <astearns> https://drafts.csswg.org/css-grid/#issue-bbfb3743
  fantasai: We had the argument on margins and padding yesterday.
  fantasai: We have an issue on row-gap and column-gap and
            potentially using grid-row-gap instead of reusing the
            multicol column-gap property.
  fantasai: We don't have to worry about the normal value which is
            good. Also if we're using grid layout to go over a
            multi-col we would have a conflict between the two
            properties which I can imagine us doing if we started
            working on a snap-to-grid modle. If we do that we'd
            have a conflict with the properties.

  Rossen: Do you recall the reason we converged on reusing the gap
  fantasai: Because it was there and why not reuse it?
  TabAtkins: I suspect it's better to switch to grid-specific.
  Rossen: I'm not opposed if there's a necessity.
  fantasai: I'm not sure we'll run into it, but it's possible.
  fantasai: Knowing if we'll run into this issue requires writing
            the entire snap-to-grid module, and that's far in the
  Rossen: If you insist to add it as a preventative measure, we

  Florian: Is that the topic at NY where we decided to share?
  fantasai: We discussed adding the properties. We had a resolution
            to add them. We had row-gap for multi-col and why not
            reuse that. But I thought we might use grid-template-*
            with grid-to-snap. That was an issue where I thought
            we might run into this as a conflict. It might be a
            problem, or it might not.

  fantasai: Anybody else have a comment?
  plinss: It's probably good to separate them to grid-column-gap and
          grid-row-gap. You don't want grid-gap to reset multi-col
          gap, do you?
  fantasai: It does now. I don't want it to. It doesn't make too
            much of a difference.
  rachelandrew: The advantage of grid spec is if it acts the same as
                multi-col, they'll expect it to behave the same in
                the future so if there's any change the different
                name will keep people from expecting the same
  fantasai: Arguments not in favor?
  fantasai: Might as well do that then.

  RESOLVED: switch row-gap/column-gap to grid-column-gap and
            grid-row-gap and maintain grid-gap as the shorthand name.

  plinss: Would it be better for grid-gap-column/-row?
  TabAtkins: We don't have a strong tendency on the current names.
             They have row or column at the end, but they are all
             grids and columns.
  TabAtkins: I'd be fine either way.
  fantasai: I think leaverou prefers matching the short hand
  <leaverou> re:shorthand conventions, that ship has sailed
  <leaverou> but yeah, consistency is good

  TabAtkins: Do you want to say grid-gap-rows/-columns
  fantasai: Do we plural in any others?
  TabAtkins: Yes.
  fantasai: Then yeah, they should be plural.
  fantasai: Let's be consistent as much as possible.
  hober: It sounds more like the gap in the rows.
  esprehn: I think grid-row-gap sounds better.
  TabAtkins: Two choices grid-row-gap and grid-gap-row

  TabAtkins: Why don't we just poll authors?
  TabAtkins: This is easy to poll for.
  <leaverou> I can poll authors pretty quickly and have results today
  TabAtkins: If everybody is okay, we'll set up a poll.
  fantasai: leaverou said she'll set up a poll.
  <rachelandrew> i've got a lot of people on my list re layout stuff
                 so I can share any naming poll with that group

  plinss: To throw another wrench, maybe use gutter instead of gap?
  fantasai: But we have column-gap and want to be consistent.
  plinss: But you call them gutterse
  fantasai: I do that in the letter-spacing section, too: I use
            "Tracking" as a title so people searching for either
            term in the table of contents would find what they're
            looking for.
  plinss: It's just a suggestion.
  TabAtkins: grid-gutter-rows does work.
  hober: You're describing the gutter not the gap.
  dbaron: The way you described it make it sound like they count as
  TabAtkins: You have gutter rows and regular rows and for layout
             they're both rows.
  TabAtkins: You have to use row or column in there somewhere.
  TabAtkins: We'll figure this out.

stretch keyword

  TabAtkins: I think next set is the repeat stuff, or there another?
  <astearns> https://drafts.csswg.org/css-grid/#issue-db68a1c3
  fantasai: Let me grab issue 10. There's a stretch keyword for the
            alignment properties. We have align-content and
            justify-content, which operate on the grid tracks. You
            can align to either side, or center, or distribute space
            just like in flexbox.
  fantasai: You can also use stretch which appears in flexbox. It
            only stretches tracks that are auto sized. Alternate
            pption would be to stretch all the tracks. I wanted to
            know opinions.
  Rossen: Stretching tracks that are fixed. If anything we can add
          an anonymous column that could be stretched. I wouldn't be
          in favor of stretching.
  plinss: If people do tile images and they stretch, it'll break.

  RESOLVED: stretch stretches auto-sized tracks only


  fantasai: Last issue is the auto-filling.
  TabAtkins: Issue 5/6 in the draft.
  [they head to the whiteboard]
  <astearns> http://www.w3.org/TR/2015/WD-css-grid-1-20150806/#repeat-auto
  <rachelandrew> something like this demo (which works in Blink with
                 exp. web platform features flag on)
  fantasai: The general issue is there's a common use case people
            want to solve. You have some arbitrary set of items and
            want to arrange them into a grid. Say I have 7 items and
            I want to have them in a tiled layout. People are trying
            to do this with flexbox and if you don't have exactly
            enough to fill up the last line, they don't line up into
            a grid.
  fantasai: Let's say I have 450px and I have 7 items that are
            100px, I would have 4 columns and 3 rows;
            there's an extra 50 px and I'd say please stretch to
            take up that extra bit of space.
  fantasai: If you do that with flex you'll get an awkwardly sized
            bottom row. That's fine for flexbox, it's not supposed
            to be a grid. However, that's the goal for the grid spec.
            This is a common need. The problem we have right now is
            that grid-template-rows/columns require you to know how
            many rows/columns you have in the main dimension.
  fantasai: Sizing depends on placement, which depends on knowing
            the number of tracks in at least one dimension.
  fantasai: We have a repeat() function, but it takes a fixed number.
            So we were thinking lets do an auto keyword so that it
            repeats as necessary to fill the container.

  fantasai: However, there were two cases that authors wanted.
  fantasai: Let's say my viewport is x big and I only have two items.
            What that will do, the repeat syntax was repeat(auto,
            100px) and it will fill with the number of columns that
            would fit.
  fantasai: Sometimes the author might want the fallback to do
            something different like center them. That wouldn't
            work now because we have four columns, two of which are
            empty, but still take up space.
  fantasai: So one idea we had was have two different keywords:
            auto-fit and auto-fill. Auto-fill would do as we
            described: fill the container with as many repetitions
            as necessary. Auto-fit would do that, but then after
            placement would drop all the empty columns.

  fantasai: There's a limitation on this syntax, this is pre-layout
            so we have to put a fixed size. We can't say start
            putting content in and that's how wide it should be.
            That is a common use case, and you might not want to be
            explicit, but we don't want to do a full pass to find
            the size of the items before we start placing them.
  TabAtkins: The repeat(auto) syntaxes, you'd have a second fixed
             grammar that only had lengths and percentages. You also
             could only have one repeat(auto) function as well.

  fantasai: That's the best solution we've come up with. We think
            this is an important use case.
  TabAtkins: Like catalogs where they want to lay things out, they
             know what size, but they don't know how many things
             there will be.

  fantasai: So that's the best solution we've come up with, we're
            looking for comments and if you have anything better to
            add. Like we could add a size of the first item keyword.
  TabAtkins: Um, no, I don't like it.
  fantasai: It would work for most cases.
  TabAtkins: If everything is going to be the same size, that's when
             you would know the size up front anyway.
  fantasai: Okay.

  fantasai: Thoughts from the WG?
  Rossen: Good.
  fantasai: Anybody else?
  gregwhitworth: Seems good.
  Florian: The use case makes sense, but for the solution I'm too
           far out of my comfort zone.
  TabAtkins: It may not be optimal, but it does the job.
  fantasai: Resolve to add it?
  rachelandrew: I spent a lot of time thinking it through, I can't
                think of a better way to describe it. It's
                complicated, but it makes sense.
  TabAtkins: We think we're iterating toward fixture with the spec.

  RESOLVED: Add repeat(auto-fill) and repeat(auto-fit)

  fantasai: That's pretty much it for design issues. There's a ton
            of issues like add an example, this needs more pictures.
            We're planning to make these last edits and we're done
            and we need review to suss out more issues.
  TabAtkins: We're feature complete and want to move it to bug fix
             and eventual CR. We need review of stuff, there is an
             issue or two in the layout algorithm that we'd like
             review on.
  fantasai: We'd like to publish a WD after these last edits are in.
            That will be the last WD unless people raise issues,
            which we encourage people to do.
  TabAtkins: So, are people okay to resolve to publish after we do
             the edits, or review after we edit before publish?

  RESOLVED: Publish grid WD after the above edits

  plinss: Okay for grid?
  TabAtkins: That's it for grid.
Received on Friday, 11 September 2015 18:32:58 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:33 UTC