Re: [CSSWG][css-grid-layout] Updated WD of CSS Grid Layout

On Tue, Apr 23, 2013 at 11:18 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
> On Apr 21, 2013, at 10:05 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>> I don't understand how it allows anything to overlap.  Your syntax
>> example defined nine areas, and (it appears) used their names as
>> informal indicators of edges.
>
> Whereas with your syntax, you would define nine areas by naming the 4
> horizontal and 4 vertical lines that divide and surround them, and assigning
> the names to those lines instead of to the areas between the lines, right? I
> don't see how that is a functional difference. The spec already says that:

My point is that *you are naming lines* (or at least, the columns/rows
at the edges of the region), you're just doing it with areas *that
you're not going to actually use*.  You're producing weird areas in a
template solely for the purpose of naming the edges/corners of
*implied* regions that may have nothing to do with the areas in
question, and may not even *overlap* with the areas used to name them.
 (If you're using an area to name the column edges of a region, they
only need to be in the right column - they can be in *any* row in the
grid, even far from where the region will actually cover.)

Please produce a non-trivial example with real names, and it'll be
more obvious why using areas as fake line name hosts is a bad idea.

[skipping a bunch of line-by-line responses that are answered by the above]

>> and which can interfere
>> with the auto-placement algorithm.
>
> Perhaps you can explain that part, and how auto placement is better when
> using named lines. The named lines example in the spec only showed items
> aligning to edges, which is exactly what my version is doing. Are you saying
> that auto-flowed content is going to flow into one set of boxes in the grid,
> but other content would be placed into the grid to align to different
> completely edges defined by lines? I don't get that from the spec, which
> says that the lines are creating the same grid areas that I would use for
> alignment.

I'm not sure I understand this confusion.  I think it might be that
you don't understand what the auto-placement algorithm does, or what
it's used for?

Auto-placement automatically flows items into empty cells in the grid,
one by one.  This allows you to grid-align a bunch of similar items
without having to explicitly place every single one, which can be
annoying in the best case and impossible (because the number of items
is dynamic) in the worst case.  For example, you can put a bunch of
product images into a grid, setting the number of items you want per
row and having it automatically create new rows as necessary.

A cell is "empty" if there is no grid-template area covering it, and
no explicitly positioned or already-auto-positioned item covering it.


> So, example 3 in the spec shows how to use named lines. The measurements
> given are apparently not where the preceding line is, but the width of the
> grid area after it. So, there is no name for the left-most edge, and the
> right-most has no measurement.

The names are for the lines.  The measurements are sizing functions
for the tracks between the lines.

I'm not sure what you mean by "there is no name for the left-most
edge".  The left-most edge is named "start".

> Here is how I would modify that to use named areas, and to make it more
> consistent with how example 2 works:

Yes, for a 1-dimensional example, when there's no need to give the
same line two names, you can produce a roughly equivalent example with
grid-template.

This is a misuse of the template, though, or perhaps more correctly a
"hack" - grid-template is meant to define areas for you to use in
'grid-area', but these areas are worthless for that purpose.

> Sorry; it is really the 'grid-auto-flow' property that I find confusing. But
> maybe it is just the example that is failing to clarify. You have this:
>
> form > input, form > select {
>     /* Place all controls in the "controls" column and
>        automatically find the next available row. */
>     grid-column: "controls";
>     grid-row: auto;
>   }
>
> But to me it looks like it is being put into the next available column,
> after having auto-flowed the label into the first column. If you had
> 'grid-column: auto', wouldn't it do the same thing in that grid?

This example is somewhat complex, certainly.

You need grid-auto-flow:rows, because that makes the grid grow by
adding rows when it runs out of space, rather than adding columns.
This is somewhat confusing, because none of the elements use the
normal "seek out the next position in the row" behavior, because they
lock down the column they belong in.

You can't just use "grid-column: auto", because you don't want items
to fall into the "oversized" column, which they otherwise will
(because it's empty).

> Anyway, I fail to see how using the grid areas as the naming/numbering
> reference for edge-to-edge placement makes more of a difference for
> repeating tracks than using explicitly named or numbered lines on the edges
> of those same grid areas.because you wrote a syntax that defines grid line
> names to repeat instead of grid areas? That is a just secondary fault of
> assuming named lines are needed. Here are a couple alternatives, using your
> Example 12:
[snip examples]

Your example syntaxes for repetition don't work as well,
unfortunately.  For one, they repeat named grid areas, which is a
no-no - the cells of a grid area have to be contiguous and form a
solid rectangle.  For two, they're much less flexible, only allowing
you to define a fully repeating grid, not a grid with some repeating
parts and some singular parts, which is common in examples we've seen
(often a "content area" will be filled with repeated columns/rows).

~TJ

Received on Tuesday, 23 April 2013 19:00:15 UTC