This page contains material to facilitate discussion of issues surrounding the CSS3 Grid Layout module.

Link to current Working Draft:http://www.w3.org/TR/css3-grid-layout/

Link to current Editor's draft: http://dev.w3.org/csswg/css3-grid-align/

Three scenarios where boxes are stretch aligned that we could make agree in their behavior (or not):

1. Resolving the width and left/right margins of block-level boxes that “stretch” to touch the edges of their containing block
2. Resolving the cross size property and cross margins of a flex item such that its margin box stretches to touch the cross edges of its line
3. Resolving the width or height and margins of a grid item such that the box touches the edges of its grid cell (now calling this grid-area in most recent ED)

In each of these cases we satisfy the equation:

margin_size1 + border_size1 + padding_size1 + box_size + padding_size2 + border_size2 + margin_size2 == space afforded to item by parent container

1. If box_size is auto then first we adjust it up or down to make the equation true while respecting any min/max constraints on the applicable dimension
2. If that isn't sufficient we do additional adjustments on margins
   1. If only one margin was auto we adjust that one to make the equation true
   2. If both of the margins were auto we take the additional space needed to make the equation true and divide it by 2 then assign it to each margin
   3. If neither margin is auto (the over-constrained case), we take the second margin (nearest the ending edge) and adjust it to make the equation true

When both margins are auto though, and the box is larger than the space afforded to it by its container, a paragraph of section 9.3 for css3-box http://www.w3.org/TR/css3-box/#blockwidth says:

If ‘width’ is not ‘auto’ and ‘border-left-width’ + ‘padding-left’ + ‘width’ + ‘padding-right’ + ‘border-right-width’ + scrollbar width (if any) (plus any of ‘margin-left’ or ‘margin-right’ that are not ‘auto’) is larger than the width of the containing block, then any ‘auto’ values for ‘margin-left’ or ‘margin-right’ are, for the following rules, treated as zero. We should drop this paragraph. It causes blocks that are wider than their parent not to be centered (unlike blocks that are narrower), which looks strange.

The Grid ignores the paragraph above as suggested so that two auto margins will always result in a centered item whenever width/height is not auto. I noticed that Flexbox keeps the last sentence per its example 10 in the latest ED http://dev.w3.org/csswg/css3-flexbox/#auto-margins.

Options:

1. Snap to definition of Flex Items i.e. every child element is a valid Grid Item and runs of loose text are surrounded in anonymous items (current ED)
2. Make contents of a Grid Element wrapped in a default Grid Item (which is an anonymous flow) and then pull elements out of that flow and onto grid by using the grid-* properties

The first option works well with auto-positioning while the second would require the author to write a (trivial) rule to declare that all elements are in fact grid items: #grid > * { grid-area: auto; } The second option could be used position descendants of the grid in addition to just children, but breaks from the pattern established by flexbox and would differ from IE's current implementation.

We have four leaf level properties and five proposed shorthands. Are we overdoing it? See table below from Hamburg F2F.

1. Scoping of Grid Layout and Template Layout specs
2. Drop named lines from this level of Grid Layout
3. Adopting column-gap etc., adding row equivalents, to handle gutters

1. grid-flow: row | column | layer
2. rename grid-rows –> grid-row-tracks, grid-columns –> grid-column-tracks
3. auto/fit-content becomes fit-content
4. grid positioning properties:

=

1. auto-placement is progressive pack w/ pointer @ start before corner
2. auto-placement vs. anonymous block
3. default value of grid-flow?
4. using “display: grid” vs implied grid lines
5. default track sizing is an open issue, if you have ideas let us know

Grid-layer vs. z-index property for Grid

Grid-layer is currently used to control the stacking of grid items in a grid element; one example of this that is mentioned in the current Editor's Draft would be using Grid to build a range control where the “thumb” of the control is displayed on top of the underlying track. However, grid-layer is in many ways similar to the existing z-index property. Is a separate property needed, or can z-index replace the grid-layer property?

We have three primary goals w/r/t stacking Grid Items:

1. Grid Items draw atomically. Like positioned elements, Grid has among its primary scenarios the ability to overlap and layer its items (see section 2.4 Grid Layering of Elements). To avoid a counter-intuitive interleaving of backgrounds, floats, and inline content, Grid Items should form a new stacking context.
2. Grid Items are in front of the Grid Element, even when the Grid Item is given a negative z-index. Imagine an author using a tool, right-clicking an item and choosing “send to back” from a context menu. The tool should set a negative z-index on the Grid Item and not have the Grid Item disappear behind the background of the Grid Element. Also, if a nested Grid is given a positive z-index, it should not cover its Grid Items. Therefore we need the Grid Element to serve as a stacking context for its Grid Items.
3. We want to avoid impacting any positioning scenarios. It would be unexpected if the author inadvertently changed the containing block or the stacking context for a positioned descendant just by inserting a Grid layout in its ancestry.

Z-index should be used to replace the grid-layer property (i.e. z-index applies to statically-positioned Grid Items.) Specifically, in cases where Grid Items overlap, z-index provides control over the drawing order of Grid Items. Both Grid elements and Grid Items generate a stacking context as described for floats (step 5, section 14) in the CSS3 Box Model.

Note also that using z-index in place of grid-layer has been previously discussed on the www-styling mailing list.

Fractional-track sizing algorithm update

The grid-sizing algorithm introduced in the previous Editor's Draft did not define the expected behavior for sizing a fractionally-sized track (e.g. 1fr, 2fr,…) when a Grid Element was shrink-to-fit. This should be addressed so that future implementations of Grid Layout behave predictably across platforms.

We propose to modify the existing grid sizing algorithm as follows: if the Grid Element is shrink-to-fit, then we set the size of a fractional track (i.e. determine the size of a '1fr' track) by making sure that 1) the proportions of all fractional tracks are preserved (e.g. a '1fr' track is half the size of a '2fr' track) and 2) fractional tracks are large enough contain all Grid Items that span them. If the Grid Element is not shrink-to-fit, then the algorithm follows its current path. The specific algorithm updates can be found in step 6 of the updated Editor's Draft.