Re: [css3-grid] Notes from the Grid discussion

On Tue, Nov 27, 2012 at 1:19 PM, Ojan Vafai <ojan@chromium.org> wrote:
> It's hard to understand the below without understanding how the lines get
> named.

Largely irrelevant for our examples, but pretend we have a separate
property that lets us declare named lines explicitly, by providing a
name and a distance.

> Also, why are you able to repeat the names of lines? That seems
> unnecessarily confusing.

Really useful, actually!  In traditional print-based grids, there are
often repeated patterns of lines at different separation distances.
Allowing multiple lines with the same name matches this practice,
allowing someone to easily say "the third content-column".  It also
makes it easier to add "snapping" abilities in the future, where you
snap the size of an element so that it stretches between two given
grid-lines.

A quick diversion - I forgot to put in part of the initial discussion
about use-cases.  Let me rectify this.

There are two primary and distinct uses of "grids" in layouts.  The
first, drawn from table-based layouts, is well-served by the current
Grid Layout spec.  In this, content is put "into" a grid, and the grid
lines can move around to accommodate the content.  The second, drawn
from print-based layouts, isn't well-served yet.  In this, content is
put "onto" a grid; the grid lines are static, and content responds to
the grid by resizing itself.

While Grid Layout is still mostly geared toward the former, it would
be nice for it to accommodate the latter as well.  Named lines, in
general, are helpful for both.  Multiple lines of the same name (or,
in other words, multiple lines of a particular "type") are helpful
mostly for the latter.

We plan to do both by keeping grid-start/end/etc as they currently
are, putting things "into" the grid, and then doing the "onto" with
another set of properties, maybe a new 'position' value.

> What do we gain from adding lines instead of keeping it just grid areas?
> Most of your examples below seem much more confusing to me in the new
> syntax.

The examples were mostly there just to illustrate the syntax for the
purpose of this discussion.

The old syntax is directly translatable into the new syntax really
simply.  Rather than "grid-column-position: 2; grid-column-span: 3;",
you just say "grid-start: 2; grid-end: offset 3;".  The rest of the
variations let you do *more* than you can do with the current syntax -
for example, switching so that -end uses a number and -start uses an
offset lets you position relative to the *end* of the grid.
Specifying both as numbers (or named lines) lets you easily span
between two things without having to worry about how many columns were
used between those two lines.

In many simple cases, you don't gain too much, and just sticking with
areas will be fine; this is why the shorthands will continue to
support this model.  But it appears that there are a decent number of
more complex cases where just using areas is limiting or weird.

>> Non-Positioned Contents
>> ====================
>> For stuff that isn't a grid item (what this means tbd; does it mean that
>> none of the grid-* properties are set?  Is there an explicit indicator, like
>> display-outside:grid-item;?), flow it all together, wrap it in an anonymous
>> grid item, and position that.
>
>
> I'd prefer that we be consistent with flexbox and force all immediate
> children of the grid to be grid-items regardless of their display property.
> Obviously, text will need to be wrapped in an anonymous grid items still.
> This is simpler for browser developers to implement and for authors to use.

While this is simpler, it's not great.  It's the "you're doing
something wrong, so we're just doing minimal damage control to
compensate" model.  I think this is fine for Flexbox, but for Grid,
there's value in, for example, just setting a grid on <body>, pulling
out elements that'll go into cells, and flowing the rest into the
"body cell".  This was allowed by the older Template spec, and I
really liked the functionality.

>> Grid Item Descendants (not children)
>> ==============================
>> Unsure right now whether to allow descendants of a grid to become grid
>> items.  There are three choices:
>>
>> 1. No.
>> 2. Only if they're children after eliminating boxes via "display-box:
>> contents;".  (Flexbox wants to do this too - lets you use wrappers in the
>> DOM, but ignore them for styling.)
>> 3. Yes, arbitrarily - when you're a "grid item" (see the note in the
>> previous section), you seek out your nearest ancestor grid and position
>> yourself in it.
>>
>> If (3) is chosen, what happens to the following?
>> <div id=A display:grid>
>>   <div id=B display:grid-item>
>>     <div id=C display:grid-item></div>
>>   </div>
>> </div>
>>
>> Is C allowed to jump out of its parent, so that B and C end up
>> layout-level siblings in A's grid?  Or do you need a clear path to the
>> ancestor grid, without intervening grid-items, so that C computes to
>> "block-level" instead?
>>
>> If we decide on (1) or (2), we can always open things up later.  If we
>> choose (3), and then the latter option (C computes to "block-level"), we can
>> also open that up in the future, by allowing grid items to explicitly select
>> the grid they want.
>
>
> I strongly prefer that we leave 3 for a future version of the spec. I think
> we can meet the majority of the use-cases with considerably less
> implementation cost if we pass on 3 for now.

I agree - my preference is (2).

~TJ

Received on Tuesday, 27 November 2012 22:33:55 UTC