- From: Simon Sapin <simon.sapin@exyr.org>
- Date: Wed, 23 Apr 2014 19:53:24 +0100
- To: fantasai <fantasai.lists@inkedblade.net>, www-style@w3.org
On 18/04/2014 17:25, fantasai wrote: > On 02/07/2014 07:27 AM, Simon Sapin wrote: >> Hi, >> >> After careful reading of the Grid spec, it’s unclear to >> me how the used width and height of a grid container is >> determined, especially when they compute to 'auto'. > > OK, we've added some text about this: > > # A grid container is sized using the rules of the > # formatting context in which it participates. > # As a block-level box in a block formatting context, > # it is sized like any other block-level box that > # establishes a formatting context, and as an > # inline-level box in an inline formatting context it > # is sized as an atomic inline-level box (such as an > # inline-block). In both inline and block formatting > # contexts, the grid container’s auto block size is > # its max-content size. > > I've stashed it currently in the Grid Containers section > http://dev.w3.org/csswg/css-grid/#grid-containers > but if there's a better place, let me know... > > The Block & Inline Layout spec should be defining most > of this, I think, in terms generic enough to handle all > formatting context roots, but maybe this is ok for now. > >> (Same for auto margins, btw.) > > The margins of a box are determined by the formatting > context in which it participates, so that's not really > the job of the Grid spec... It needs to handle grid > item margins, not its own. I agree that ideally this is not the job of the Grid spec, but this refers to a general layout rule this is not (yet?) defined anywhere. I’m ignoring the "Dangerously outdated" css-box, and CSS 2 defines a series of specfic cases such as non-replaced block in normal flow and block-level table. I don’t know what you mean by "like any other block-level box". It could be based on the container (like blocks) or on the content (like tables and images). Both sound reasonable for grid containers to me. Unless we can start a Block & Inline Layout spec now and have Grid reference it normatively, Grid needs to have some normative definitions here (which could be marked as "expected to move into a future Block & Inline Layout spec" in a note.) There is also an issue with circular definitions. Assuming 'auto' computed values, blocks have their inline size determined based on the parent, and their block size based on their content. The grid track sizing algorithm, however, depends on the "available space" which is defined as that size not determined yet. -- Simon Sapin
Received on Wednesday, 23 April 2014 18:53:51 UTC