W3C home > Mailing lists > Public > www-style@w3.org > October 2010

Re: [css3-grid-align] -- proposed new grid layout module

From: Andrew Fedoniouk <andrew.fedoniouk@live.com>
Date: Sun, 31 Oct 2010 13:58:51 -0700
Message-ID: <BAY141-DS69F731B7D555F389A6DB6F8470@phx.gbl>
To: "Alex Mogilevsky" <alexmog@microsoft.com>, <www-style@w3.org>
Well put, Alex!

But here are my 5 cents as this appears close enough to my initial
flow:grid approach[2] to implement such a layout manager.

The only difference in my case is that I am [re]using
left/top/right/bottom properties (they are not used in position:static)
for defining cell element binding to rows/columns.

So this of yours:
  #board    { grid-column: 2; grid-row: 1; grid-row-span: 2 }
in my case is this:
  #board    { left: 2#; top:1#; bottom:2# }
where '#' is a special "grid location unit".

My variant of defining bindings to rows/columns is very far from being
perfect. Yours appears as to be better but they share the same set
of problems.

So all below is based on real experience using them and why
I've decided to drop this layout manager in favor of something close
to the Template[1].

At some point I've decided to add Drag-n-Drop support to
CSS. DnD in CSS is actually another and interesting story per se,
but for now is this: it raised some set of requirements that forced
me to revisit problem of grid alike layout[manager]s in CSS.

1) definition of a child of the Grid should not contain
grid positions like grid-column and grid-row in your case.
It is highly desirable to define layout in one place that you can
[re]define children flow on all-or-none basis.
Think about of moving #board element in runtime to different container
that uses its own grid layout.

2) Way of binding of elements to cells has to be as less error prone
as possible. E.g. it is too easy to get element overlapping with either
my flow:grid or display:grid of yours.
It is also very easy to get grids that will have e.g. only [1,1] and
[10,10] cells filled by some elements with the rest of the grid filled by
holes that still occupy space (due to the grid-columns). Grid inconsistency
errors (overlapping and holes) are very easy to get and very hard to find
and maintain.

3) Dimensions of cells must be dependent only on
dimensions of elements in rows/columns.
If you have some element with min-width:150px placed
into column with grid-columns: 100px then it is not
clear who will win. Dimensions defined in two
different places, as an option, is bad as it is.

4) Ideally any layout manager shall keep congruency
of element position on screen and its position in the DOM.
E.g. if you have consequent elements A, B and C in the DOM then
B should be in between A and C visually. Vertically, horizontally or in 
flow.

For example DnD in flow:horizontal (e.g. tabs) containers.
In such layouts, for any given mouse location, task of finding
insertion DOM position of the element is trivial and
very predictable (for the user).

In fact #4 is not only about DnD but also about text selection on the
page, tab[index] navigations, screen readers (accessibility) and so on.
I mean that the Grid layout must be used as an exception - as a last
resort when no other natural layouts are working.

That means we ought to have *system* of layouts where the
Grid (in one form or another) is just one of them.
If we have a system of layout[manager]s then we shall try to unify
them. If all of them use flexes then we shall have flex units defined.
E.g. your proposal uses 'fr' units, David use "box-flex:" property and Bert
use '*' for flexes in his proposal.

And again about use of 'display' for defining layout managers.
I believe that we agreed already that it will not fly.
What if I want to layout *children* of display:listitem elements
using your grid layout? Or [inline-]table-cell?

So far layouts like these:
http://www.interoperabilitybridges.com/css3-grid-align/CSS%20Grid%20Alignment_files/game-portrait.png
and 
http://www.interoperabilitybridges.com/css3-grid-align/CSS%20Grid%20Alignment_files/game-landscape.png
we use templates with numbers - indexes of DOM elements:

flow: "1 2"
      "3 2"
      "4 4"
      "5 5";

flow: "1 4"
      "2 4"
      "3 5";

and flex units on width/height properties of cell elements.


[1] http://www.w3.org/TR/2007/WD-css3-layout-20070809/
[2] http://www.terrainformatica.com/htmlayout/flow.whtm

-- 
Andrew Fedoniouk

http://terrainformatica.com


>From: Alex Mogilevsky
>Sent: Tuesday, October 26, 2010 6:20 PM
>To: www-style@w3.org
>Subject: [css3-grid-align] -- proposed new grid layout module
>
>
>There is increased interest lately in layout mechanisms that are good for
>developing application UI.  To address this interest, the IE team would
>like to explore a two-dimensional grid layout that is consistent with
>existing layout systems, while providing new capabilities using algorithms
>that are clean and well-defined.
>
>Attached [1] is a proposed specification for "grid alignment".
>It targets applications in the same space as Template Layout, Tables
>(historically and often inappropriately), Grid Positioning, and also
>multiple script solutions.
>
>The goal of this proposal is not to compete with existing modules, but
>rather add and integrate, to make progress towards something that is a
>good match for the target requirements, while also generating interest
>from multiple vendors. The particular syntax and behavior shows what the
>IE team would be interested in, but by no means are we settled on the
>details.
>
>We would like to present this proposal at the F2F.
>
>Looking forward to feedback and discussion.
>Alex
>
>[1] http://www.interoperabilitybridges.com/css3-grid-align/ 
Received on Sunday, 31 October 2010 20:59:32 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:33 GMT