W3C home > Mailing lists > Public > www-style@w3.org > August 2013

Re: [css3-grid-layout] Alternative Grid Layout proposal

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 19 Aug 2013 13:49:33 -0700
Message-ID: <CAAWBYDA6yAWKnigqe9u=OzjmaAiHXFvwrWDTccDJ5mp9DyMKhA@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: www-style list <www-style@w3.org>
On Mon, Oct 29, 2012 at 3:52 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> On 09/03/2012 06:24 PM, Linss, Peter wrote:
>> During the San Diego F2F I was tasked to come up with an alternative
>> proposal for grid layout. This is addressing two issues, the first being
>> preserving the concept of named grid lines (and harmonizing those names with
>> the names in the grid template syntax). I believe the level of indirection
>> between grid lines and grid items is extremely valuable. The second issue is
>> my opinion that the current direction of the grid layout module has become
>> narrowly focused on the task of application UI layout and is not providing
>> the kind of behavior typically expected from traditional typographic layout
>> grids. I feel the current draft is more reminiscent of tables or 2D flexbox
>> than a typographic grid layout paradigm.
>>
>> To that end, here is my proposal. I believe it's compatible with all the
>> capabilities of the existing grid layout proposal, while also allowing a
>> more flexible usage more in keeping with traditional page layout.
>
>
> I think it's great that you've thought through all of this, but I have some
> problems with your model:
>
>  a) The grid is logical, not physical. It can't use top/left/bottom/right
>     for positioning.
>  b) The 'position' property in CSS specifies a positioning scheme, not an
>     actual position,  so it feels inappropriate for it to take a position
>     now. More significantly, the 'position' property cannot now be turned
>     into a shorthand that resets top/left/bottom/right, as it has never
>     done so before.
>
> There's also the fundamental issue of a snap-to-grid model, in which content
> is in-flow but shifts to align to the grid lines (like the line grid), and a
> fit-grid-to-content model, in which the content determines the position of
> grid lines. I cannot see how they can co-exist in an interactive way.
>
> Also in a snap-to-grid model, you want to specify which edges (margin,
> border, padding, or content) snap to the grid, not just which sides snap
> to which grid lines. There are some ideas about that in the line-grid draft,
> but it's not a problem you are solving here.
>
> That said, I think it's possible to bring in your line-based view as the
> addressing model for the current grid layout model. To do that, you'd want
> to
>   1. Introduce grid-start/end/etc. properties in place of the current
>      -position/-span properties.
>   2. Define, as you suggest, the grid template to implicitly define a
>      series of named lines, and allow the grid-positioning properties
>      to accept those names as values, with appropriate shorthanding.
>   3. Figure out some way of representing, in each grid-line assignment,
>      either exact line coordinates or a span (perhaps restricted to a
>      particular line class) from the opposite side.
>
> Then this becomes mostly a syntax problem on top of the existing grid
> layout model.

Just to follow up on old threads, though Peter is definitely aware of
this work now...

The Grid Layout spec now does roughly this.  At its basic level it's
about positioning items by specifying which lines each of its edges
are attached to.  The shorthands grid-row and grid-column make it
easier to pretend that you're placing the item in a particular
row/column (rather than specifying where its edges go), which works
better with some people's intuition, and the grid-area shorthand lets
you simply place the item in a named area, defined by the template.

The basic grid positioning is a "content-based" grid, where the
spacing of the lines responds to the content within it (if you allow
it to).  Additionally, you can use abspos to do a "snap-to-grid",
where items respond to the grid's definition instead.  We haven't yet
filled in the necessary hole to let an item span as many grid lines as
necessary, but at least you can easily position items on the grid
(rather than *in* the grid) now.

~TJ
Received on Monday, 19 August 2013 20:50:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:33 UTC