- From: François REMY <fremycompany_pub@yahoo.fr>
- Date: Fri, 24 Feb 2012 23:54:44 +0100
- To: "Phil Cupp" <pcupp@microsoft.com>
- Cc: "CSS 3 W3C Group" <www-style@w3.org>
<< [pcupp] I think there are a lot of strong opinions about template syntax. Here my view is opposite your own. I think one can see the shape of the grid in the multi-line example and not the alternative you proposed. >> Maybe because I'm doing a lot of Math and that stacking vertically an horizontal fraction bar flow seems really natural to me. I also like it because you can use it to construct recursive layouts. I mean, if I have a string-template that achive something, I can simply copy-paste that string at any place of any other template to create a composition of the initial layout and the new. Like: "abc" create three columns + "(x/y)" create two rows => "ab(x/y)" create three column whose last one is divided into two rows => "ab(x/(rst))" create a grid which has three columns whose last one is divided into two rows; from those two rows, the second one is splitted into three columns. A good IDE could even manage to replace the letters for me to avoid conflicts. I don't know how I can do compositing using any other technique that the one I'm presenting here. Neither the older template proposal or the numeral definition allows it. << [pcupp] I agree a weakness of the template syntax is maintenance of the template definition. You trade the pain of making ascii art for a visual representation of the grid. Authors that currently take the time to create and maintain ascii art in the comments of their code will likely enjoy a new ability to have their art actually be the layout definition. Authors that choose not to spend time on such things don't need a template syntax at all. Just define row and column definitions and (optionally) use named lines. >> Makes my code even less readable and *much* longer. Or I did not understand your proposal. Could you provide an example of how you would achieve the three parts of my example with the minimal number of changes between each steps ? My take was : (1) #grid { grid-template: "ab(x/y)" } .a { grid-cell: a; } .b { grid-cell: b; } .x { grid-cell: x; } .y { grid-cell: y; } (2) [EDIT] #grid { grid-template: "ab(x/y)(r/t/u)" } .r { grid-cell: r; } .t { grid-cell: t; } .u { grid-cell: u; } (3) [EDIT] #grid { grid-template: "ab(x/y)(rs/t/u)" } .s { grid-cell: s; } Because numeral definition of rows/columns doesn't allow to do composition (hand-written composition, I meant), I don't think it can be my proposal at any task that requires compositing. You'll have to change row-span/column-span all the time to acomodate the row insertion. And, if I trust my intuition, composition is the way you build an actual grid design. You start with the major elements. Then you refine your model to take in considerations smaller sections. A model that I can use the way I think is a big plus for me. But there's a possibility I'm the only one who thinks like that that I don't neglect.
Received on Friday, 24 February 2012 22:55:17 UTC