W3C home > Mailing lists > Public > www-style@w3.org > February 2012

Re: [css3-grid-layout] semantic zoom in grid's templates

From: François REMY <fremycompany_pub@yahoo.fr>
Date: Fri, 24 Feb 2012 23:54:44 +0100
Message-ID: <56425BF6FB9646A4BC312EB31C7D3BBD@FREMYD2>
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 :

#grid { grid-template: "ab(x/y)" }
.a { grid-cell: a; }
.b { grid-cell: b; }
.x { grid-cell: x; }
.y { grid-cell: y; }

[EDIT] #grid { grid-template: "ab(x/y)(r/t/u)" }
.r { grid-cell: r; }
.t { grid-cell: t; }
.u { grid-cell: u; }

[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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:12 UTC