- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Tue, 23 Apr 2013 11:18:51 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Ojan Vafai <ojan@chromium.org>, fantasai <fantasai.lists@inkedblade.net>, Julien Chaffraix <jchaffraix@google.com>, Elliott Sprehn <esprehn@google.com>, "www-style@w3.org" <www-style@w3.org>
- Message-Id: <79FA16A6-0A4B-4EB6-AD7A-BD74AF413F92@gmail.com>
On Apr 21, 2013, at 10:05 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: > On Sun, Apr 21, 2013 at 6:54 AM, Brad Kemper <brad.kemper@gmail.com> wrote: >> On Apr 20, 2013, at 8:46 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: >>> On Sat, Apr 20, 2013 at 7:04 PM, Brad Kemper <brad.kemper@gmail.com> wrote: >>>> On Apr 19, 2013, at 6:03 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: >>>>> We had discussions two f2fs ago about relying solely on named areas to >>>>> provide names. It's not usable. (I tried.) >>>> >>>> It seems to have changed a lot since then, though, and I'm not sure the current melange of named grid areas and named grid lines is better. As I dig into the current version more, I'm finding it pretty confusing. >>> >>> It hasn't changed in any way relevant to the discussion; we've just >>> rearranged some syntax. The underlying issue is still there - lines >>> are tied to a more generic concept of "regions", which can overlap and >>> nest, unlike grid areas. >> >> The proposed syntax I suggested would allow grid regions to overlap, by aligning to the edges of the specified regions. You still haven't said why that wouldn't work, or why you'd need named or numbered lines instead of implied edges of named or numbered grid areas. > > 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: > A grid area can be named explicitly using the ¡®grid-template¡¯ property of the grid container, or referenced implicitly by its bounding grid lines. So why should the way the 9 areas are defined make a difference for how they work? I am just using a named grid area as a reference for the placement instead of a named grid line. It is still the same grid of areas and the lines that divide them. I am just leaving the lines as implicit. > Doing this readably means that you need to have areas placed just > right, Instead of lines around the areas placed just right? > and given names appropriate to the region, Instead of names appropriate to the divisions of the regions? > even if nothing is > actually being directly positioned in the area There is no less positioning "in" the area than when you create named lines to define the edges of the areas. > (because it doesn't > actually cover the right cells, due to the lack of overlapping). That's what you keep saying, that there can't be overlapping, but I don't see why not. > This > is the exact problem we came up with during the f2f discussions, where > you'll end up with "dummy" areas used solely to provide names for > region edges, but are otherwise worthless, How are they any more worthless than the regions defined by lines you name in your scheme? They are no less dummy regions than the spaces you create by naming the lines instead of the spaces between the lines. But in your scheme, one extra name is needed for each dimension. > 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. > It was this exact type of example that led me to finally convert to > the named lines camp. 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. Here is how I would modify that to use named areas, and to make it more consistent with how example 2 works: <style type="text/css"> #grid { display: grid; /* no new naming or grid sizing method compared to example 2 */ grid-template: "start" "track-start" "thumb-start" "thumb-end" "track-end" "end"; } grid-definition-columns: auto 0.5fr auto auto 0.5fr auto; } /* Below the lines are referred to by leading or trailing grid area edges * (leading for *-start and trailing for *-end) * Grid edge references can also work with layered grid items * that have overlapping areas of different shapes like the thumb * and track parts in this example. */ #lower-label { grid-column-start: "start" } #track { grid-column: "track-start" / "track-end"; align-self: center } #upper-label { grid-column-end: "end"; } /* Fill parts are drawn above the track so set z-index to non-auto. */ #lower-fill { grid-column: "track-start" / "thumb-start"; align-self: end; z-index: 5 } #upper-fill { grid-column: "thumb-end" / "track-end"; align-self: start; z-index: 5 } /* Thumb is the topmost part; assign it the highest z-index value. */ #thumb { grid-column: "thumb-start" / "thumb-end"; z-index: 10 } </style> <div id="grid"> <div id="lower-label">Lower Label</div> <div id="upper-label">Upper Label</div> <div id="track">Track</div> <div id="lower-fill">Lower Fill</div> <div id="upper-fill">Upper Fill</div> <div id="thumb">Thumb</div> </div> >> I'm not sure what you mean by nesting requiring an explicit reference to grid lines, and why an implicit reference to a grid area's edge wouldn't suffice. >> >>> They can also repeat, which isn't compatible >>> with grid areas. >> >> I haven't included any comments yet about how baffling the syntax is for repeating. > > You specify a segment of lines and tracks, and how many times it > should be repeated. When positioning, you indicate which repetition > to use. What do you find confusing? This should probably be a separate thread, but I'll answer here anyway. 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? 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: This example shows two equivalent ways of writing the same grid definition. Both ways produce a grid with a single row and four "main" columns, each 250px wide, surrounded by 10px "gutter" columns. <style> #grid { display: grid; grid-template: . "content-column" . "content-column" . "content-column" . "content-column" . grid-definition-columns: 10px 250px 10px 250px 10px 250px 10px 250px 10px; grid-definition-rows: 1fr; } /* Equivalent definition. */ #grid { display: grid; grid-template: . "content-column" . grid-definition-columns: repeat(4, 10px 250px) 10px; /* repeating the widths also expands the template with repeating named grid areas */ grid-definition-rows: 1fr; } </style> Or, maybe this syntax: This example shows two equivalent ways of writing the same grid definition. Both ways produce a grid with a single row and four "main" columns, each 250px wide, surrounded by 10px "gutter" columns. <style> #grid { display: grid; grid-template: . "content-column" . "content-column" . "content-column" . "content-column" . grid-definition-columns: 10px 250px 10px 250px 10px 250px 10px 250px 10px; grid-definition-rows: 1fr; } /* Equivalent definition. */ #grid { display: grid; grid-template: repeat-columns(4, . "content-column") . grid-definition-columns: 10px 250px 10px; /* repeating the template slots also repeats the widths of those slots */ grid-definition-rows: 1fr; } </style>
Received on Tuesday, 23 April 2013 18:19:24 UTC