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

On Apr 23, 2013, at 11:59 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

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

No, I am naming areas, in the exact same way that areas are named in your example 2. I am not requiring a new way of naming in order to reference the edge. There is only one edge per grid-column-start|end property that matters. If it is for the grid-column-start property, then it is the start edge that matters. If it is for a grid-column-end property, then it is the end edge that matters. This is a lot more intuitive and readable than a bunch of lengths and names interspersed in one list, especially since one naming scheme is already established and will do well here too, without adding extra complexity. 

> , you're just doing it with areas *that
> you're not going to actually use*.  

No, they are no more useless than the areas produced anyway with 'grid-definition-columns' and 'grid-definition-rows', whether you insert names into those properties or not. We're both creating the same areas, I'm just naming them in a more consistent way. 

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

That is what you are doing too. Each of your names in a row is associated with widths created by 'grid-definition-columns', just as mine are. How does your scheme have more to do with the "areas in question"? The placement of your lines is a direct result of the widths of the "weird areas" you create. The measurements in 'grid-definition-columns' are not line locations as I once thought by reading the example (that is why the last named line doesn't have a length after it), they are grid-area widths, whose existence creates those "weird areas". 

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

I still don't get what you're saying. By using explicate line names instead of implicit edges, you get the lines to overlap more? It doesn't make sense. My way allows you to use area names from other rows to align to, which is usually why a designer cares about edges/lines anyway.

I'm assuming region means grid area, but it is confusing when you switch terminology.

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

My last email adapted the example in the spec! You please produce a non-trivial example of something realistic in which named lines would work, but what I described would not. You might start with something that does not use auto-placement, since you make that sound like a separate problem.

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

I think I do. You are talking about section 6.3, and specifically 6.3.1 (which uses terms like "major axis position", "minor axis position", and "minor axis 'auto' values", without actually defining what these terms mean, which makes it much harder to read). The rest of 6.3 seems relatively clear so far.

But you still aren't explaining why named lines are better. 

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

I'm with you so far.

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

What's a cell? I thought from your previous e-mail that we weren't supposed to use that term here (although the spec does, undefined, in a few places). Do you mean grid area? :p 

I also don't know for sure what you mean by "if there is no grid-template area covering it". Do you mean grid areas defined by a template cannot accept auto-placed content? That seems like an unnecessary restriction, if so. If I have 'grid-auto-flow: rows', and a template-defined grid area called 'labels', and my actual label elements have 'grid-column: labels', then i'd have the first label go there, and then (assuming there are no more "labels" grid items in that row) a duplicate template row should be automatically created for the second one, without merging vertically same-named grid areas. That would be much more intuitive to me than what is in the spec with named lines, and simpler too.

Also I don't see examples in the spec that combine the named line based overlapping placement with auto placement, which is why I asked about that before, if that is the situation where you think my way will break. I assume that is possible, and seems to be what you're hot about, although I'm not quite sure. The algorithm mentions "explicitly-defined grid items", and I guess that means grid items with the "line based placement" of section 6.1, though it isn't too clear.

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

It just goes to show how confusing I find the named line syntax and the examples for it to be. I get it now, but when I first read example and saw pairs of names and length, it wasn't obvious why "end" had no length, and I didn't notice that there was a "fill-split" line, as it was more intuitive to me to associate the name with whatever area was to the left of the line (in order to explain to myself why "end" had no length to its right). 

As I say, I understand the syntax better now, but it is much less intuitive and obvious than if we could just name the areas. The areas have more meaning to associate a name with, which is why in your example every line except "fill split" is named after an associated area (the area to the right of the line for the first half of the names, and the area to the left of the line for the second half of the names).

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

So are you saying that the premier example used by the spec to explain grid layering and edge/line-based placement is a hack because it is one dimensional, or that my more intuitive version is a hack because it wasn't how you originally conceived of using templates? It is not worthless for the purpose of doing edge-based layout. What's worthless is creating a separate, less intuitive naming system when the first, easier to understand one is adequate and simpler. 

The template can contain more than one row, and named areas can be on any row, so I fail to see how this is a problem. The lines exist to create places to align content to, so a template for that content is a natural thing. Please provide a realistic example where you think my approach won't work.

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

OK, maybe it is just the comment that is less than clear, given that it is same wording as for "label", but only "label" is creating new rows in this example. 

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

Only because that is how the spec is currently worded. I would just say that contiguous areas that are only contiguous due to auto placement or repetition do not merge into a single area. And if it is not there already somewhere, that non-contiguous areas with the same name are valid as separate grid areas. 

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

How do you figure? Didn't my example code show a repeating group plus one non-repeating area?

Received on Wednesday, 24 April 2013 23:46:17 UTC