- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 02 Jul 2013 22:52:16 -0700
- 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