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

[CSSWG] Minutes Tokyo F2F 2013-06-07 Fri Noonish: Grid Layout

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 02 Jul 2013 22:52:16 -0700
Message-ID: <51D3BC10.4030908@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
F2F Planning
------------

   Aiming for NYC in February. Tentatively scheduled for NYC.

CSS Grid Layout
---------------

   - RESOLVED: snap-to-grid is out-of-scope for CSS Grid Layout module

   - Discussed use of 'position: grid' to pull descendant elements up
     into an ancestor grid.

   - RESOLVED: abspos for grid items accepted as described in the spec,
               with auto meaning use padding edge of containing box

   - RESOLVED: change issue 8 into a more general issue about how to
               collapse a grid track

   - Plan to change grid-definition* and grid-template properties to:
       grid-template-[rows|columns|areas]
     and look into defining 'grid-template' as a shorthand, using syntax
     similar to that in the Template module.

   - Long discussion of default handling of grid container's contents.
     Tentatively resolved on making 'grid-auto-flow: row' the default;
     issue still open for future discussion.

====== Full minutes below ======

Meeting: Cascading Style Sheets (CSS) Working Group F2F
Date: 07 June 2013

F2F Planning
------------

   <dbaron> topic: February-or-so Face-to-Face
   dbaron: want to do a doodle for scheduling
   [discussion of continents, probably North America's turn]
   [discussion of who can host, and who just hosted]
   Feb is NYC tentative
   <dbaron> (some were going to look into hosting in California too, I think?)

CSS Grid Layout
---------------
Scribe: Liam

   <TabAtkins> http://dev.w3.org/csswg/css-grid/
   Tab: section 1...
   [question of scope from fantasai]
   Issue is about snapping items to grid.
   You can already align things in grid layout, but this is more about
   sizing things to a fixed grid.
   Proposal from Tab is to push snap-to-grid off to a later spec
   no objections
   glazou: accepted.
   RESOLVED: snap-to-grid is out-of-scope for CSS Grid Layout module

   Tab: section 4 issue 3
   positions of things not explicitly given a grid position
   [Tab goes through the four options in the issue]
   fantasai: [draws on the board]
     1. always auto-position
        (by default)
     2. put unpositioned elements in slot 1 1
     3. add ability to define a default slot, and then do either 1 or 2

   Bert: first look at area, then look at flow, then look at normal positions
         just a process
   Tab: this is for the case there's no explicit position
   Bert: if you don't have a grid area there's still flow-into that may
         give you a position
   fantasai: you have a doc, e.g 5 elements in body, and the only style
             is display:grid on the body
   fantasai: so these sub-elements have no explicit styles at all
   Bert: then they all go into the default slot
   Tab: what happens if you don't define a default slot?
   Bert: but 1 1 might be an empty slot
   Rossen: we currently do 1 1

   toggling display: grid on/off will have no effect in that case,
   if you put all of the items in one anonymous grid item

   Alan: if you had discontiguous elements you might not want to put them
         all into the same container
   fantasai: advantage of auto-positioning is that things don't pile on top
             of each other
   advantage of everything piling up is that you don't change the size of
   the grid, but then you can't see the top
   Tab: if you're using grid and not positioning things, you're doing it wrong
   Rossen, we were strongly considering (4)
     4. Flow everything together into the default slot.
   e.g. if there are 3 P elements you get all 3 stacked separately
   Alan: it runs into the complications we had with named flows
         e.g. margins collapsing

   Tab: In Flexbox now, all elements get coerced into flex items
   other option: auto-position everything with grid-auto-flow: row
   margins will no longer collapse when grid is toggled but it'll be more
     like flexbox
   fantasai: [agrees]
   so either auto-position, or do the flow
   Bert: I'd like this to be more compatible with regions
   Tab: wherever we have slot pseudo-elements they should be able to accept
        grid as well

   fantasai: I'm inclined to go with 1
   fantasai: ... consistent with the way flexbox works, so you can easily
             switch from flexbox to grid

   <dbaron> I'm concerned about the difficulty of doing 4.
   Alan: 4 isn't quite regions, still in same parent
   Tab: but taking discontiguous flow elements together
   Tab: doing 4 is basically equiv. to taking all the flow items out and
        then taking what is left
   and putting it into one big anonymous grid item in the default slot
   dbaron: presumably you can't have absolute positioning on grid items
   Tab: right, then it's not a grid item
   Alan: default slot is * or 1 1 if there isn't a * ?
   Tab: [agrees]
   Tab: old template draft used @ for it
   Tab: we'll add properties for specifying it
   Alan: if you have more than one cell marked with a * ?
   Bert: an error if disjoint

   fantasai: [elimination game for other alternatives]
     1 stacking everything on top of each other, i.e. auto position by default
   Rossen: that's what we do today
     4: flow everything together into the default slot.
   Bert: 1-1 might be empty, "."
   Tab: so, if there's no explicit default slot defined, use a row-major
        search to find the first non-empty slot and use that.
   Alan: if you want to avoid overlap, sometimes you'll have to create a new row.
   Tab: sometimes you'll need to specify a default position
   Bert: ok
   this is fallback behaviour anyway
   decision: accept proposal 4 for issue 3 in section 4 of css-grid, flow
             everything not explicitly grid-positioned together into a single
             item which is then auto-positioned, into the default slot or the
             first available slot

   issue 4, non-children grid items
   [[  This is a proposal to create the ability to have descendants of a
       grid item participate in a grid layout, similar to the behavior
       defined by the Template Layout module. ]]
   position: grid makes a non-grid item an item in the nearest enclosing
     grid; if there's no such ancestor the item remains in the flow.
   dbaron: what if it gives no position?
   Alan: it becomes a grid item
   Tab: so it must be auto-positioned
   Tab: how about if we only do this if the item has both position: grid
        and an explicit position?
   plinss: what about using the fact that it's positioned in a grid instead
           of using position: grid?
   Tab: we do need an explicit flag, "I want to be a grid item"
   Tab: I'd be fine amending this to say you must also provide explicit
        positioning in addition to grid: position
   If you're positioning to a named area/gridline, and the nearest grid
   doesn't have that, the spec says keep moving up the tree until you
   find a grid with that line
   or we could say, you failed
   benefits - you can refer to the page grid anywhere in the document
   plinss: is that true if you're asking for a line in your grid?
   fantasai: if you wanted to make that work you could just say position:grid
             on that item
   Tab: a normal line item referencing a line not in its grid just pops up?
   fantasai: what if you specify two grid lines and they come from different
             grids?
   Tab: goes in the first grid it can find
   Bert: so we're using the position property to turn this on?
   Tab: yes, if you're not a direct child of a grid
   we have other ways we might want to use the position properties so we
   want to make it an explicit switch
   Bert: you only do that for elements that are themselves of grid items?
   fantasai: any descendant of a grid can take position: grid and become
             a participant in that grid
   Tab: what if you can't find something with that name?
   maybe they should be auto-positioned in the nearest grid?
   if you're a grandchild of a grid you need to opt in explicitly, if you're
     a child it's automatic
   Bert: default, you're inside your parent, that's always the case, so you
         want to become a grid item to be positioned differently, ok
   Rossen: but if you have a name line that doesn't match you'll have a
           silent fail, Peter was saying, and that's not [good]
   if you don't find any lines you should still be positioned in the closest
     grid you find
   Alan: be good to separate the fallback from the sub-grid that works
   Tab: [agreed]
   Alan: on the subgrid that works I agree with Peter, position:grid isn't
         needed, using the grid properties should make you a grid item
   plinss: not ok because there are other uses for the properties
   Tab: section 4.2 has the abspos case

   [4.2. Absolutely-positioned Grid Children http://dev.w3.org/csswg/css-grid/#abspos-items]
   fantasai: [draws a diagram]
   fantasai: everything is like abs-pos except that if the containing block
             is a grid you can restrict your effective containing block to
             a set of grid lines
   tab, peter [discuss possible changes to abs pos]
   Tab: we don't want to change abs-pos too much
   plinss: but the abs-pos'd items don't affect the grid layout
   plinss: what if fixed position?
   dbaron: with transforms, fixed works like abspos
   Tab: assuming fixed-pos can find a containing grid it should work just
        like abs
   Tab: example: {
     grid-row-start: 2, auto
     grid-row-end: auto;
   }
   Tab: wondering about this only for abs-pos'd items
   fantasai: if it's all auto you use the outer edge
   plinss: a little bothered it's different for abspos and grid items
   plinss: need to make sure auto gets you a regular abs-pos behaviour
   Tab: you can use the grid-col properties to change your containing block,
        for abs-pos
   plinss: normal abs positioning of the column edge, [scribe missed]
   fantasai: if you have a grid ... [draws] that's 1 x 1 , autosized ...
   my vertical gridlines will be separated by the size of the content,
   not the container
   e.g. align: center should center that box (the grid) in the containing block
   so the abs pos first and last grid line, you'll align to those lines,
   wherever they end up being
   may or may not correspond to the content of the box
   abspos auto means the normal containing block edge
   plinss: but if it's a grid item it means something slightly different
   fantasai, Tab: [agree]
   RESOLVED: abspos for grid items accepted as described in the spec, with
             auto meaning use padding edge of containing box
   plinss: to clarify, display:grid isn't always an abs pos containing block?
   fantasai, Tab: correct
   plinss: can we add "containing-block: always"?

   back to issue 5, non-children grid items
   plinss: these items only behave oddly if you position them absolutely
   <dbaron> (plinss arguing that you shouldn't need position:grid, you can
             just apply the stuff in section 4.1 when not position:absolute)
   Tab: we still want an explicit indicator [for grid-item-ness] so you
        can opt into auto-flow
   plinss: so you can have a position: grid, but only necessary if you don't
           want auto?
   Tab: yes
   Tab: now have an additional problem, if you have position: grid, a named
        line, and can't find it, so we don't know what grid to put you in.
   We could say you remain in flow.
   If you're a real grid item, your parent is a grid container, and we can't
     find your lines we default you to auto.
   So auto-positioning or default slot.
   If you're grid descendent we don't want that behaviour.
   So are we OK with saying no, you're not a grid item, if we can't find
     the line?
   Bert: first step is going up the tree, maybe all the way up to the page
   Tab: assuming we did that and can't find the grid?
   Don't want to put grid items into the default slot,
   so it stays in flow in normal positioning.
   plinns: if auto-positioning is turned on there's no reason why we couldn't
           auto-position it ...
   So maybe "we do nothing" is the fallback, i.e. ignore the position: grid.
   Tab: seems reasonable
   ok
   [accepted]

   Alan: so if you have a grid container, one of its direct children, but
         you put position: grid on it
   Tab: it goes into the default slot, normal flow, position: grid will act
        like position: static in that case
   plinns: it seems to me all direct children of a grid will compute to
           position: grid
   Bert: that depends on the position property
   position: static means they are in the normal flow
   fantasai: [disagrees]
   Tab: sometimes we do want to put things with position: grid in the default
        slot, if they are grid items
   Tab: I'd be OK with position computing to grid
   Tab: we don't do it to flexbox but we don't have children there
   Rossen: how do you break out of your grid in that case?
   plinss: same as before, you'd use a name of a higher grid line
   Bert: you'd put a div element wrapper in there
   <Bert> (which, of course, is not desirable)

   fantasai: I don't like that if you're a child of a grid you can suddenly
             jump around.
   plinns: but aren't immediate children grid items anyway?
   fantasai: yes, but nothing makes them jump about out of the grid
   liam: is there a way to prevent content? e.g., third party content:
         don't want advertiser to position outside of their third-party
         content?
   Tab: use a seamless iframe, solves these kinds of problems generally

   <dbaron> I'm not crazy about all the use of the 'position' property
            (and 'display:grid' vs. 'position:grid' is especially confusing)
   <stearns> +1 dbaron, particularly in that position:grid really means
             something like supra-grid or jump-into-an-ancestor's-grid
   dbaron: I'm generally unhappy about adding more uses of the position property
   dbaron: since the 'position' property is mostly a list of things that
           should have been values of 'display' instead

   Bert: we can reduce by one based on presence of template
   Tab: we wanted an explicit flag
   you can set none of the properties and you'll be autopositioned
   Bert: which is more common?
   fantasai: depends what you're doing, e.g. a catalogue where you want
             items in a grid
   Tab: we can do display: grid-item
   plinss: but then you lose display: auto
   Tab: current values of position should have been position
   dbaron: position: fixed is really a display value, position: relative is
           an unrelated feature
   Tab: could add display-outside: grid-item instead of position:grid

   fantasai: it's getting complicated
   fantasai: I like how flex-box is very straight-forward
   fantasai: whereas here, when you turn on display: grid, shouldn't
             something happen?
   Tab: are you saying we should default grid properties to more than a 1x1 grid?
   fantasai: we don't generally have things jumping around reparenting themselves
   fantasauL it should be self-contained, you turn on grid and everything
             looks like a grid
   plinss: that _is_ what's going to happen
   [discussion about reparenting]
   fantasai: I want the jumping to be explicit opt-in from the jumping item
   Tab: that only happens if you're using useless grid item properties
   fantasai: *I don't want setting something on a parent to trigger the
             ability of a child to jump out*

   Rossen: do we need all this for level 1?
   Bert: yes!
   Rossen: I mean the jumping out
   Alan: if we don't do it now, we'd have to invent entirely new properties
         to get this in the future
   Tab: can possibly do it more simply and integrated way right now

   plinss: the child is already opting into some grid behaviour
   plinss: if you're explicitly opting in to some grid line, why should
           you have to turn on another property to make that work?
   fantasai: [scribe couldn't hear]
   Tab: probably opting in will be needed
   plinss: position: snap, or something
   plinss: what if everyone had to say position: grid?
   plinss: and no magical behaviour
   plinss: because now just being a child of a grid makes you magic
   Bert: this should be like columns, not flexbox
   Tab: but flexbox isn't used in the same case, and neither is columns
   Bert: if you position yourself in the grid you get a position in the
         grid, doesn't matter if it's your parent
   Tab: opting in to auto-position would have to be explicit
   Tab: couldn't just turn on grid and have everything positioned into rows
   fantasai: want turning display:grid on to make a grid that's one column
             (if you don't do anything else)
   plinss: better to do other issues for next 15 minutes and come back to this
   Tab: skipping to next issue

   4.3 issue 8 visibility
   "Or should the track size be set to 0 regardless of its sizing function? "
   Tab: make visibility collapse, remove it from the grid, but still affect
        on sizing
   collapse is like visibility: hidden, except,
   if everything in a track collapses the track size drops to zero
   a. is this reasonable?
   b. should this be intrinsic size of the track or forced size of the track?
   dbaron: if you set some of the items to visibility: collapsed, no change
           on track size?
   Tab: yes
   dbaron: that's not the same as tables
   Bert: for tables, you set it on the table row or col; can't do that here
   dbaron: the intermediate state seems weird
   if the feature is useful enough to exist, I'd be OK to change for each
     collapse change
   Tab: then it's same as display: none
   dbaron: OK, I see why you did what you did
   dbaron: but it's still annoying
   Tab: there's a case for table-like behaviour where you can collapse away
        a col or row, but sounds like it might not be a popular way to do it
   dbaron: for reference we still haven't defined how the table thing works!
   Tab: probably should kill this section and think about it some more
   RESOLVED: change issue 8 into a more general issue about the feature

   issue 9
   [[ Since all three properties define the explicit grid, would it make
      sense to give them all a common prefix (and possibly a shorthand
      unifying them, as in Bert's ‘grid’ shorthand)? Current thoughts:
      ‘grid-template’ as the shorthand, with ‘grid-template-rows/columns/slots’
      as the longhands, or ‘grid-definition’ as the shorthand, with
      ‘grid-definition-rows/columns/template’ as the longhands. Other
      suggestions welcome.
   ]]
   Tab: right now you have:
           grid-definition-rows
           grid-definition-columns
           grid-template
   Tab: [suggests some alternate names for the properties]
           A. grid-template-[rows|columns|slots]
           B. grid-definition-[rows|columns|slots]
   dbaron: so the rows and cols properties are really giving the sizes of
           each column/row
   Tab: rows and columns also name lines and give the numbers of rows/columns
   Bert: I used the shorter name for defining grids
   Tab: You'll more likely be using the positioning properties. These
        definitions are once per container, not once per item. So we
        went with shorter names for positioning.
   Bert: I want to use grids more as regions, so I don't need all these
         row and column properties, just naming the "region" is enough.
   TabAtkins: There are strong use cases for [explicit definition properties]
   Bert: don't like the word definition, maybe "size"?
   Tab: we want a common prefix
   Bert: "grid" is the common prefix
   fantasai: it's not just sizes, also names
   <dbaron> I'm happy with A or B, probably slightly prefer A.
   <jerenkrantz> prefer A
   Tab: I'd love to be able to say grid-rows and grid-columns, but I want
        grid-row and grid-column more, and don't want both at the same time.
   Tab: maybe we can say "area" instead of "slots"?
   Tab: replaces A with grid-template-[rows|cols|areas]
   so, grid-template-[rows|columns|areas]
   and grid-template is a short-hand using Bert's draft

   [discussion of Bert's syntax for shorthand, plinss and tab agree it
    might need work]
   Tab: could say it's a slightly odd shorthand, can't omit the template
        from the shorthand, but this is weird
   Bert: it's not weird!
   [discussion, do you need to mention the template in the shorthand property?]
   Tab: given a 3x3 you have to do ". . ." ". . ." ".. . ."

[lunch]

Scribe: dino

   Tab: we deferred a couple of issues
   Tab: 1. Position: grid stuff. Peter, Elika and I decided on something.
   Tab: position:grid on anything makes it a grid item, and makes it jump
        up the tree looking for lines.
   Tab: this leads to interesting auto-placement....
   dbaron: [interrupts]
   <stearns> normal grid children do not jump up the grid
   Tab: ok, cool.
   Tab: we propose eliminate grid-auto-flow:none, switch initial value to
        row (grid-overflow), and have that as the default behaviour
   Tab: this has the benefit that it is close in apparent behaviour to the
        default cell (with display: grid)
   Tab: and acts grid-like when you apply more of the grid properties
   TabAtkins: and matches flexbox more closely

   TabAtkins: -> unambiguous behaviour when pos:grid items that can't find
                 lines (or are auto). They act the same as a grid child.
              -> find nearest grid, and become auto-flow item there
   Alan: so you can no longer have pos:grid and have it remain in the flow
   TabAtkins: correct
   Bert: means I can't use the same grid for templates.
   TabAtkins: the region behaviour should be addressed separately.
   TabAtkins: this is simpler overall.
   Bert: but less useful
   Bert: everything has to be parent child
   TabAtkins: no, use position: grid

   Bert: I want to use props starting with grid. they are useful.
   Bert: they work like regions. content flows into the grid.
   Bert: this is reversed. when i set the grid properties on an element,
         i need to duplicate the properties on children.
   TabAtkins: (disagrees)
   TabAtkins: a. regions lets you do everything right now
   TabAtkins: b. if we want to do this later, it's easy
   [ Bert requests maintaining existing behaviour. Tab explains that this
     is like flexbox ]
   Bert: It is easier if you have markup designed to behave that way.
         This is not normally the case.
   Bert: My approach is easier. If you want something floated, you put a
         property on it. That's what removes it from the normal flow.
   TabAtkins: I understand there are strong reasons for your way, but my
              way is much more simple.
   Bert: They were simple before too.

   fantasai: The point of having everything become a grid is that display:grid
             makes things appear like a grid.
   fantasai: Set rows, you immediately get that number of rows, etc.
   fantasai: We wanted this for flexbox, and we're following here.
   TabAtkins: We're proposing to start with this simple model, and add
              your case later.
   Bert: Both behaviours are useful. The nice thing was that you could use
         the same properties to set up for both.
   TabAtkins: you can still do this.
   [ disagreement about how many properties each case needs to set ]
   Bert: I've tried many different examples...
   TabAtkins: All document-centric.
   TabAtkins: App-centric gravitates towards my model.
   Bert: Yeah, it is very common to have flowing text. I don't want to have
         to set two properties.
   fantasai: When you have flowing text you normally have a parent/child
             relationship.
   Bert: Disagree.
   TabAtkins: Can do that later by changing grid:auto-flow into a new value.
   Alan: I don't understand how this addresses Bert's case.
   TabAtkins: Once we add it, it is simple to turn on.

   Bert: Why not have it as part of the shorthand? It could say either the
        template or a keyword positioning v flowing.
   TabAtkins: Right now grid:autoflow is not part of the shorthand.
              We could add that.

   TabAtkins: This is not necessarily new stuff, we'd just changing what
              the auto value does.
   Bert: You could also use the display property as the switch.
   TabAtkins: It is simple to add this later. Are we happy to change our
              default behaviour over to this?
   Bert: Flexbox is the wrong model to follow. Multicolumn is a better example.
   TabAtkins: I'm not trying to justify flexbox.
   TabAtkins: Can you live with the change I suggested?
   Bert: It's a radical change
   TabAtkins: no, it's just the initial value of one property.
   Bert: Syntax wise yes. but requires a new template layout model.
   TabAtkins: [disagrees]

   Bert: What does the default slot become?
   TabAtkins: When you use the flowing behaviour you define what the slot is.
              We don't have to worry about this in default.
   Bert: [explains a complicated example in a manner that would be difficult
          to minute, using hand gestures]
   TabAtkins: [answers the example :]
   TabAtkins: The two things you can't mix are the two types of auto-positioning.
              Use regions for that.
   Bert: I have a grid element, with a template, it isn't auto positioned,
         with some child that I do want positioned
   Bert: Do I then have to use pos:grid?
   TabAtkins: No, use grid-area.
   TabAtkins: The rest are auto-flowed.
   TabAtkins: look at grid: auto-flow and do what that says

   <Rossen>  #grid { grid-auto-flow: rows; display: grid; }
             #grid > * { grid-area: auto }
   Rossen: is that enough to get all of the auto positioned in a row?
   TabAtkins: not even that much. just set display:grid.
   <Rossen>  #grid { grid-auto-flow: columns; display: grid; }
             #grid > * { grid-area: auto }
   TabAtkins: we're just saying the default value should be grid-auto-flow: rows

   Bert: you still have to set two properties together
   TabAtkins: one of them has to be privileged
   Bert: what is interaction between flow-into and grid-area?
   TabAtkins: I have no idea and don't want to think about it now.
   Bert: We will have to prepare for it.
   TabAtkins: In the regions draft, sure.
   Bert: flow-into is used, and grid-area is auto....
   TabAtkins: YES
   Bert: NO
   TabAtkins: NO
   Bert: YES
   plinss: Suggest accepting tab's proposal, bert's objection noted, we will
          discuss it again.
   Alan: The proposal said you'd change the default and defer none? Could
         we leave it in the draft for now?
   TabAtkins: yes.
   <dbaron> (grid-autoflow: none)
   RESOLVED: Accept proposal to make 'grid-auto-flow: row' the default,
             Bert's objection noted, we will discuss it again (issue marked
             in spec)

   TabAtkins: Shorthand.
   TabAtkins: Accept bert's shorthand with tiny changes (separators)?
   plinss: Do this later.
Received on Wednesday, 3 July 2013 05:52:45 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 3 July 2013 05:52:46 UTC