- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 19 Sep 2013 01:22:33 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Grid Layout
-----------
- RESOLVED: Formally accept renaming
grid-definition-rows/grid-definition-columns/grid-template
to
grid-template-rows/grid-template-columns/grid-template-areas
- RESOLVED: Grid child staticpos is resolved as if it's the sole child.
Copy the definition over to Flexbox as well.
- RESOLVED: Add more examples to the abspos grid items section.
- RESOLVED: Named areas create implicitly named lines.
- RESOLVED: Make named areas just desugar into named lines.
- RESOLVED: Leave subgrids in level 1, mark it and its component parts
individually as at-risk.
- RESOLVED: getComputedStyle returns used values for grid-template-rows/columns.
- RESOLVED: Don't change 'grid-area' to 'grid-field'.
====== Full minutes below ======
Present:
Glenn Adams (Cox)
Rossen Atanassov (Microsoft)
Tab Atkins (Google)
Mihai Balan (Adobe)
David Baron (Mozilla)
Bert Bos (W3C)
Tantek Çelik (Mozilla)
John Daggett (Mozilla, via phone+IRC)
fantasai (Mozilla)
Sylvain Galineau (Adobe)
Daniel Glazman (Disruptive Innovations)
Israel Hilerio (Microsoft)
Koji Ishii (Rakuten)
Kawabata (NTT)
Ian Kirkpatrick (Google)
Håkon Lie (Opera)
Peter Linss (HP)
Ted O'Connor (Apple)
Simon Pieters (Opera)
Simon Sapin (Mozilla)
Dirk Schultze (Adobe)
Alan Stearns (Adobe)
Shane Stevens (Google)
Leif Arne Storset (Opera)
Lea Verou (Invited Expert)
Jet Villegas (Mozilla)
Yamamoto (NTT)
Steve Zilles (Adobe)
[agenda/schedule wrangling]
http://wiki.csswg.org/planning/paris-2013#agenda
Grid Layout
-----------
Scribe: TabAtkins
<fantasai> http://www.w3.org/TR/2013/WD-css3-grid-layout-20130910/
<fantasai> http://lists.w3.org/Archives/Public/www-style/2013Aug/0353.html
<fantasai> http://lists.w3.org/Archives/Public/www-style/2013Aug/0554.html
Renaming Explicit Grid Properties
fantasai: At tokyo we discussed the renaming of grid-definition-* to
be under a grid-template-* prefix.
fantasai: Didn't resolve on it.
fantasai: Because these all define the explicit grid, we thought they
should have a common prefix, chose 'grid-template'.
fantasai: Any objections?
RESOLVED: Accept the grid-template-* renaming.
Grid Layout and Absolute Positioning
fantasai: Next issue is about abspos children of grid containers.
fantasai: Two issues.
fantasai: First is static position of grid container children.
fantasai: What we discussed among grid layout people is to make the
static position to be determined as if it were the sole grid
item in a fixed-size grid area whose padding edges coincide
with the grid container.
fantasai: In effect, this will position the child of the grid in the
top-left (start/start) corner by default, but you can use
justify-self/align-self to move it around.
fantasai: This isn't just for absposes relative to the grid; it's the
staticpos, used when you're a child of the grid even if your
abspos containing block is some other ancestor or ICB.
fantasai: This has the benefit that the alignment properties will have
an effect - you can "center" it easily, for example.
fantasai: So this gives you a little more power than just staying the
start/start corner of the grid container, but doesn't require
any interaction with the layout of the rest of the grid.
fantasai: So the one consideration with this is that it's not consistent
with Flexbox.
fantasai: Flexbox tries to find where the item would have been in the
flow if it was a real flex child.
fantasai: We could try to do that with Grid, but it's more complicated
due to 2d. Or we can go back and change Flexbox to have this
definition.
TabAtkins: Last time we discussed this, strongest voice for current
flexbox behavior was Brad, so I'd like any decision to be
contingent on him approving it later.
sylvaing: Why did he want it?
fantasai: He thought it was somewhat useful. But I think for his use-cases
generally you'd want the element to be a child of one of the
grid items anyway.
fantasai: The advantage of this definition is that it's somewhat more
simple, but it's not consistent with block flow's definition.
fantasai: Same with Flexbox, though it's closer.
fantasai: Flexbox tries to be close to normal flow; I just don't think
we have strong use-cases for this.
TabAtkins: I approve of matching Grid here, so we keep the rule that a
single column/row Grid is similar to a Flexbox.
fantasai: Right, either that or try to copy Flexbox's behavior in Grid,
whatever makes them consistent.
fantasai: So I would like implementor opinions, or else I'll make the
decision myself. :)
[summarizes the discussion again for dbaron, who was messing with the door]
dbaron: Not doing what flow layout does sounds great to me.
dbaron: Fine with me to do what Grid does for Flexbox.
dbaron: I'd like to see testcases to see if there's already interop.
TabAtkins: There isn't - I know Blink doesn't follow the spec.
fantasai: Moz doesn't quite either; we have an open bug on it, and I
told dholbert to hold off on trying to fix it yet.
dbaron: Fine with me, then.
RESOLVED: Grid child staticpos is resolved as if it's the sole child,
and copy the definition over to Flexbox.
fantasai: Next abspos issue.
fantasai: We discussed in Tokyo allowing the grid-placement properties
to affect the position of an abspos item whose containing
block is the grid container.
fantasai: We talked about 'auto' indicating the padding edge of the
grid container.
fantasai: [re-explains it slower]
dbaron: Does this allow anything that grid items can't do?
TabAtkins: Somewhat. Grid items can't position onto the padding edge
unless that's a grid line.
dbaron: Is this required for anything?
TabAtkins: Somewhat, yes - it helps address the "stuff on the grid"
rather than "stuff in the grid" use-case.
dbaron: This sounds like a decent chunk of new abspos functionality.
dbaron: If there's a good reason for this, I'd expect to see more
description in the spec about it.
TabAtkins: Yeah, some of the new thing we've added are lacking in
description. Adding more sounds good for me.
fantasai: [explains the details to szilles a little better]
szilles: Why isn't there a property that changes from content to padding
edge instead?
fantasai: There's not one for abspos in general, but if we add one it'll
apply here.
szilles: I'm just extending what David's said - it seems strange to do
it this way with specific grid functionality without a switch
in general.
RESOLVED: Add more examples to the abspos section.
Implicit Named Lines and Areas
fantasai: Peter had a proposal that using the ascii-art template should
imply the creation of named lines that correspond to he named
areas' edges.
fantasai: [shows the example in the spec for grid-template-areas]
fantasai: So here there'd be four named lines generated by the "main"
area - "main-start" and "main-end" in the column dimensions,
and the same in the row dimension.
fantasai: This seemed like a pretty straightforward thing to do, so we
added it to the spec.
<dbaron> http://www.w3.org/TR/2013/WD-css3-grid-layout-20130910/#implicit-named-lines
fantasai: This acts the same as explicitly named lines, except that it
doesn't show up in the serialization of grid-template-rows/etc.
ACTION tab to add examples to implicit named lines.
<trackbot> Created ACTION-577
astearns: What happens if you have one of those templates and a
grid-template-row with the same name?
fantasai: You just end up with two lines of that name, which is already
possible to do explicitly, so it's fine.
RESOLVED: Named areas create implicitly named lines.
fantasai: The other side of Peter's proposal is that if you create four
named lines with the appropriate "foo-start/end" names, it
would implicitly create a named area.
fantasai: This is nice and symmetrical, but it has some problems.
Currently you can't have two slots of the same name - it's
invalid at the grammar level.
fantasai: But with this implicit areas, you could potentially create
multiple areas of the same name.
fantasai: Also, since you can have multiple lines of the same name,
you have to have rules for deciding *which* foo-start line
you use to generate the "foo" area.
plinss: All those complications exist anyway - you can also create two
lines named "foo-start", and if I address it by lines, I have
to resolve that.
fantasai: We have rules about how to resolve multiple lines. But we
don't currently have those rules for named areas.
astearns: But you *could* just use the same rules.
TabAtkins: So it wouldn't really create areas, it would just desugar
into the appropriate named lines.
plinss: Without this, you need to track named lines and named areas
independently. With this, you just only store lines, and the
ascii syntax just conveniently defines lines.
fantasai: So you might end up with a slot in your template named "main",
but if you make more "main-start" lines it might not actually
land in that slot.
astearns: So grid-template-rows/columns wins over areas?
TabAtkins: Not necessarily - you'd just use the normal "first line of
the name" rule, the source of that line doesn't matter.
szilles: So while you can have multiple lines of the same name, as far
as areas go, only one is useful.
RESOLVED: Make named areas just desugar into named lines.
TabAtkins: We'll need to make sure that the grammar isn't ambiguous.
fantasai: I think we just need to keep the current prioritization: given
"grid-row: foo;", first look for a "foo-start" or "foo-end"
named line, then look for "foo".
szilles: In some of the shorthands, the default for the end value is
the same as the start value. That works for areas, but not
always for lines.
fantasai: It still works, depending on your naming.
[darn, missing something]
fantasai: Say "grid-row: main". We'll then look for "main-start" or
"main-end", depending.
fantasai: If you say "grid-row: main-start", we'll first look for
"main-start-start" and "main-start-end", which probably
don't exist, so we'll look for "main-start".
szilles: Just saying you need to make sure to handle the defaults
properly as you translate them.
Collapsing
fantasai: Next issue was about collapsing grid tracks. We tried to come
up with some ideas, but don't know what to do.
Subgrids
fantasai: But first, subgrids.
fantasai: One section we fleshed out was the subgrid section.
fantasai: The goal of subgrids is that a lot of times you'll have some
portion of a grid that you want to have a border or padding,
or some semantic grouping element.
fantasai: There is an example in the spec with a bunch of labels and
inputs, and it's a jumble of siblings.
fantasai: Really, you want them to be in a list. But you couldn't make
that work with Grid, because of the <li> containers.
fantasai: So the idea of subgrid is to help with this.
fantasai: You can currently have nested grids, but they don't interact -
the two grids are independent.
fantasai: Subgrid lets the child grid align with the parent grid.
fantasai: [explains the spec example]
fantasai: Instead of giving the child its own rows and columns, we give
it a "subgrid" value.
fantasai: You can give the subgrid border/margin/padding, and that
automatically gets taken into account.
fantasai: The rules are that the number of explicit tracks in a subgrid
are given by the subgrid's own grid span.
fantasai: If the grid has an auto span, you lay it out to find out how
many tracks it'll have, and then use that as its span.
fantasai: The grid-placement properties for subgrid items are scoped
to the subgrid's lines.
fantasai: So positioning something at 1/1 doesn't put it at the parent's
1/1, it's the first lines in the subgrid.
fantasai: [draws an example]
fantasai: For making things easy, the subgrid is always stretched to
the columns it covers.
fantasai: You can specify explicit named lines in the subgrid - these
lines are only exposed in the subgrid.
fantasai: If you have an explicit span and position for the subgrid,
you know exactly which lines you correspond to in the parent
grid, and in that case you inherit the parent's line names
as well.
fantasai: We only do this in this case, because otherwise you don't
know exactly what tracks you need.
glazou: This seems complex. Are implementors actually going to do this?
fantasai: Subgrid should be in this level because otherwise people will
do horrible things, e.g. removing elements from the markup
that really should be there.
TabAtkins: In the grid layout calls, MS was okay with it.
astearns: Would it make sense to have a simpler version of subgrid,
without additional lines?
glazou: I'm just really afraid this will be at-risk.
fantasai: Problem is right now Grid makes it *impossible* to do many
layouts without stripping out proper markup.
fantasai: Subgrid makes it *possible*.
szilles: Basic subgrid (without borders/etc) isn't much different from
plain grid, right?
fantasai: Interaction of padding/etc is actually quite straightforward.
fantasai: The hard part is the interaction with the sizing algorithm.
Rossen: Priority-wise this'll be lower.
fantasai: So that was subgrids.
fantasai: Another issue was about the "resolved value" of
grid-template-rows/columns.
<sgalineau> was there some kind of resolution for this?
<fantasai> No.
<astearns> probably the resolution should be to mark subgrid as at risk
dbaron: It might be nice to both mark the whole of subgrid at-risk,
and also mark "optional" parts of it at-risk, so it's not too
scary for implementors.
tabatkins: it doesn't complicate the algorithm, it just adds these
specific complications to the algorithm
szilles: Can you scroll a subgrid?
fantasai: Yes... that would be something to mark as at-risk.
Rossen: We were thinking of doing initial layout of the subgrid, nicely
aligned with the parent grid, and then scrolling is just a
window on top of the parent grid.
Rossen: There should be no additional constraints or problems.
szilles: Another possibility is to not allow implicit placement of subgrids.
fantasai: The syntactic switch for auto span vs explicit span is already
there in the syntax, so we can't just not recognize it. :/
fantasai: We can go through and see what we can mark at-risk. But I do
believe the basic core functionality does need to be there.
RESOLVED: Leave subgrids in, mark it and its component parts individually
as at-risk.
Explicit Grid Properties' getComputedStyle
fantasai: Back to getComputedStyle.
fantasai: For compat with MS's impl, we're having gCS return the used
value rather than the computed value of these properties.
fantasai: We didn't see a clear path to make this consistent, and gCS
is already inconsistent anyway, so whatever.
fantasai: Any concerns?
dbaron: I'm in favor of having them all be computed values, but I guess
I'm okay.
fantasai: We felt the same way.
Rossen: Tooling was a big thing for us.
RESOLVED: gCS returns used values for grid-template-rows/columns.
Areas vs. Fields
fantasai: Naming issue - some people suggested we call them "grid fields"
rather than "grid areas", and adjust the property names
accordingly.
<tantek> +1 to grid areas
szilles: I believe Peter originally brought this up as being closer to
what print grids use.
leaverou: I think "areas" make more sense.
Rossen: I think we felt the same way - "area" just feels better.
sgalineau: Even with the historical argument, it's weird to only pick
one historical name, rather than all of them.
glenn: Use "cell"?
fantasai: Confusing with tables, and we already use that to mean the
intersection of two tracks.
RESOLVED: Keep 'grid-area'.
<br dur=15m>
Received on Thursday, 19 September 2013 08:23:03 UTC