- 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