- From: François REMY <fremycompany_pub@yahoo.fr>
- Date: Sun, 31 Oct 2010 22:38:24 +0100
- 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 script. 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 proposal. 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 Sunday, 31 October 2010 21:39:04 UTC