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

--------------------------------------------------
From: "François REMY" <fremycompany_pub@yahoo.fr>
Sent: Sunday, October 31, 2010 2:38 PM
To: "Andrew Fedoniouk" <news@terrainformatica.com>; "Alex Mogilevsky" 
<alexmog@microsoft.com>; <www-style@w3.org>
Subject: Re: [css3-grid-align] -- proposed new grid layout module

> ?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 script.

That is pretty easy to solve. For example in my implementation this

flow : "1 1"
        "2 3";

is an equivalent of

flow : "1 1|2 3";

so to set it from script you can use:

element.style.flow = "1 1|2 3";


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

As I said I've ended up with use element indexes rather than named
cells.

So if you have defined:
flow : "1 1"
        "2 3";
you can add in that container as many elements as you want.
They will be added as if you have defined this:
flow : "1 1"
        "2 3"
        "4 4"
        "5 5"
        ...
        "N N";

And so you can insert elements in the middle, etc.
Numbers are also not limited by char ranges.

But as I said flow:"template" is an exception - if you have
list of items then it is better to use flow:horizontal[-flow] or
flow:vertical[-flow].

Yet I've seen couple of cases where list items (<li>) by
themselves use template layout inside.

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

I am not aware about any existing implementation of grid layouts in CSS
except of mine. Will be interesting to take a look. Could you provide
a link?

>
> 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);
> }

But why not to use <table #myGrid> in this case?
I believe that for tabular data as in your case it is
exactly what doctor have prescribed, no?

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

As I said it should be a system of various layout managers that
better suit different cases. There is no silver bullet. And that is the
point.

E.g. in Java there are 8 layout managers available out of the box:
http://download.oracle.com/javase/tutorial/uiswing/layout/visual.html

I have 7 implemented so far

flow: vertical | vertical-flow |
        horizontal | horizontal-flow |
        grid | /*obsolete*/
        stack |
        "template"

all of them use flex units. This is a superset of layout
managers found in Java.

-- 
Andrew Fedoniouk

http://terrainformatica.com


>
> Regards,
> François
>
> -----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
> 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 Monday, 1 November 2010 00:41:19 UTC