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

[CSSWG] Minutes Paris F2F 2013-09-11 Wed I: Grid Layout

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 19 Sep 2013 01:22:33 -0700
Message-ID: <523AB449.9010603@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Grid Layout

   - RESOLVED: Formally accept renaming
   - 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 ======

   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]

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


   fantasai: Next issue was about collapsing grid tracks. We tried to come
             up with some ideas, but don't know what to do.


   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

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:34 UTC