Re: [css-grid] Specification confusing, needs improvement

On Wed, Aug 27, 2014 at 4:27 AM, Axel Dahmen <brille1@hotmail.com> wrote:
> Hi Tab, sorry for my late reply. I've been on vacation.

I hope you'll forgive me a similar delay, for similar reasons. ^_^

> -- (a) ----
>
> In § 1, "Introduction and Overview", it reads "but unlike tables, grid
> layout doesn’t have content structure"... However, the grid specification
> repetitively reads "columns and rows" (e.g. § 1.1, "Background and
> Motivation").
>
> If a grid layout doesn't have content structure, if "children of a grid
> container can position themselves such that they overlap and layer similar
> to positioned elements"... then it doesn't have something like "columns" and
> "rows". At most it does have "areas" or "blocks".

I don't understand the objection here.  What is meant by "content
structure" is a layout structure dictated by the elements themselves;
in tables, for example, the location of a cell is determined by its
relative position among sibling cells, and the position of its row
parent among sibling rows.  You can't change this position via CSS.
Grid is different, in that the layout of the element is unrelated to
the structure of the content; a grid item can be placed anywhere in
the grid, regardless of where it is in the source.

The use of "columns" and "rows" is completely appropriate, because the
grid is divided into columns and rows.  I don't understand your
objection to the term.

> So I suggest the wording to change:
>
> columns = areas
> rows = areas
> grid container = grid
> grid item = block
>
> This is also true for grid property names. There shouldn't be
> "grid-column-..." or "grid-row-..." properties.

As stated previously, the spec is mature at this point, and will not
change its overall structure unless some horrifying mistake is
discovered.  We're basically just in "bugfix" mode at this point.

> The specification shows ample bias on table terms, which it shouldn't.

I don't know what this means.

> There should just be a "grid-area" shorthand property defining all necessary
> values to define an area.
>
> The "grid-area" shorthand property should then unfold into separate
> "grid-area-..." properties, like "grid-area-align" etc..
>
> There could be a "grid-group" shorthand property unfolding into separate
> "grid-group-..." properties defining how "grid-area-..." items within that
> "grid-group-..." should be arranged.

I'm not sure here whether you're referring to the spec's usage of
"grid area", or your own suggested usage from earlier in your email.
In either case, I'm not sure what this suggested change means.

> -- (b) ----
>
> I don't see the true benefit of a CSS grid if there already is a CSS flex
> specification. What's the advantage? What's the distinction?
>
> Wouldn't it have been sufficient to have added a "flex-max-items" property
> to the flex specification (forcing a wrap after {n} items have been added to
> a flex group), extending the flex-flow property to "<flex-direction> ||
> <flex-wrap> || <flex-max-items>"

Flexbox and Grid are somewhat related, but solve significantly
different problems.  Flexbox is specialized for handling "linear" or
1D layouts, where items lay out one after another in a line (possibly
a broken line, but it's still a single continuous thread of layout).
Grid is specialized for handling 2D layouts, where the objects being
laid out have a complex, non-linear relationship with each other when
positioned.  Attempting to do 2D layout with Flexbox is quite
terrible, requiring a ton of fragile nesting.

> -- (c) ----
>
> The grid property definition seems too complex. Is it really necessary to
> define a grid in terms of "grid-row-start", "grid-column-start",
> "grid-row-end", and "grid-column-end"? Shouldn't these terms be confined to
> tables?

Layout defines the size and position of boxes; at minimum, this
requires four pieces of information: x, y, width, and height.  Grid
thus has four properties to handle this, which is quite natural.
(Each property can define either a position *or* a size, depending on
which is more appropriate for your particular use; we did this rather
than taking the abspos approach of using *6* properties
(left/right/width, and top/bottom/height), which can disagree with
each other if too many are specified.

> What's the benefit of defining a grid this way if table layout already
> provides such functionality?

While you can technically reproduce any Grid layout with Table layout,
doing so is absolutely terrible.  Table layout is for tables of data,
not for laying out pages and apps; Grid is specialized to handle page
layout well, and is bad at layout out data tables.

~TJ

Received on Tuesday, 16 September 2014 20:02:01 UTC