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

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

From: François REMY <fremycompany_pub@yahoo.fr>
Date: Sun, 31 Oct 2010 22:38:24 +0100
Message-ID: <90028B14C6404A7196E11AEF5854C2F8@FREMYD2>
To: "Andrew Fedoniouk" <news@terrainformatica.com>, "Alex Mogilevsky" <alexmog@microsoft.com>, <www-style@w3.org>
?If I can add my 5 cents, too, I would like to say I don't like the Template 
proposal anymore. While it seemed better at first glance, it adds a lot of 
complexity and make it difficult to modify the style dynamicly using a 

In fact, I don't think Template is easy at all. You say it's easier when you 
move your objects in the DOM. I think it's not. What if you want to put on a 
layout manager an element that previously had 'display: a' ? It becomes a 
nightmare. You should check if the template defines an 'a' slot. Then, you 
need to check if it's alreay used by another element. In such case, you need 
to modify the CSS display property of your new element to use another 
letter, which is not used in the defined template. At last, you should parse 
the content of the 'display: "aaabbb/ccddee"' property and add new line of a 
new column where you want to put your element. The ECMAScript code needed to 
do something like that is incredibly big. And you just wanted to add one 
column or one row to your display.

Template display is also non-extensible. It does not work if you don't know 
how many element you want to put on your grid. Then, you are also limited to 
the 'usable' ASCII range. What if you end up with a grid layout needing more 
than the available char range ?

On the other side, the grid proposal is already implemented in some known 
and widely used products and it's really easy to use. If you want to add a 
row, you just need to add an element specifying that row index as grid-row. 
If you want to delete the row, just drop the element. You don't need to care 
about the template. It just works.

And if you really want something fully written in CSS for your dynamic grid 
layout, you can extend the use of 'counter' and allow something like that :

#myGrid div.labelColumn {
    counter-increment: myGridRow 1;
    counter-reset: myGridColumn 1;
    grid-row: counter(myGridRow); grid-column: 1;

#myGrid div.dataColumn {
    counter-increment: myGridColumn 1;
    grid-row: counter(myGridRow);
    grid-column: counter(myGridColumn);

I don't think it's possible to do something like that with the Template 


-----Message d'origine----- 
From: Andrew Fedoniouk
Sent: Sunday, October 31, 2010 9:58 PM
To: Alex Mogilevsky ; www-style@w3.org
Subject: Re: [css3-grid-align] -- proposed new grid layout module

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

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


>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
>We would like to present this proposal at the F2F.
>Looking forward to feedback and discussion.
>[1] http://www.interoperabilitybridges.com/css3-grid-align/
Received on Sunday, 31 October 2010 21:39:04 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:40 UTC