Re: layout idea

Tab Atkins Jr. wrote:
> On Fri, Mar 13, 2009 at 3:54 PM, Jonathan Snook
> <jonathan.snook@gmail.com> wrote:
>> I've spent a little time over the past week working on an idea. I
>> don't know if it's viable or not or whether something like it has
>> already been proposed (besides Advanced Layout and the Grid module).
>> But it never hurts to pitch my own stone into the pond.
>>
>> Matrix Layouts:
>> http://snook.ca/technical/matrix-layouts/
>>
>> Along with the accompanying blog post:
>> http://snook.ca/archives/html_and_css/matrix-layouts
> 
> It feels like this is nearly exactly like Grid Layout, except not
> quite as flexible.
> 
> As well, it commits the (what I consider a) sin of defining the page's
> layout only in the aggregate - you have to know *all* of the matrix
> declarations to figure out just how many cells are in the grid.  This
> is why I dislike Andrew's grid layout as well.  The official Grid
> Layout module declares a grid explicitly on a positioning ancestor, so
> you know precisely what's going on from a single declaration.
> 
> Andrew does make an excellent point wrt the weaknesses of using the
> position property for specifying grid, namely that it prevents you
> from doing things like position:relative on the blocks afterwards.
> However, this can likely be dealt with by extending calc() to accept
> gr units as well.  That is, if you wanted to put something in a
> particular grid cell and then move it to the left by 1em, you could do
> something like:
> 
> foo {
>   position: absolute;
>   left: calc(2gr - 1em);
>   top: 1gr;
> }
> 
> Does this seem reasonable?

That will not work. As for calc():
"The expression within the parethesis is computed at the same time as 
'em' lengths are computed" [1]

At the moment of calc() execution "gr" units are not resolved yet.
And gr units are not length units strictly speaking.

> 
> I should also state that I love *both* the Grid Layout and Template
> Layout modules, and would make heavy use of both of them were they to
> exist.
> 

Template Layout is not flexible enough. Declarations like:

   body {
     height: 100%;
     display: "a   .   b   .   c"  /2em
              ".   .   .   .   ."  /1em
              "d   .   e   .   f"
              ".   .   .   .   ."  /1em
              "g   .   h   .   i"  /2em
              5em 1em  *  1em 10em}

establish fixed layout that is "nailed" to particular DOM structure.
If for some reasons you will have slightly different DOM then all this
will come apart. Think about say dynamic DOM element injections like
advertisement blocks that may easily ruin this handicraft.

I gave an example of typical situation in previous message:

Matrix/Grid solution should support things like this:

| Cell 1.1 | Cell 1.2 |
|---------------------|
| Some text here      |
|---------------------|
....
|---------------------|
| Some other lorem    |
| ipsum here          |
|---------------------|
| Cell N.1 | Cell N.2 |

Here we have four "cells" and arbitrary number of other
blocks in between.

I mean that final solution/algorithm should be stable to variable number
of elements involved. Ideally one declaration should describe class
of layouts and not just "layout of precisely 9 DOM elements" as in
example above taken from Template Layout module.

Ideally CSS solution for matrices/grids shall be
1) more powerful than <table>
2) as simple and as less invasive as possible.
In this case it will create real motivation for web developers
to use it and for UA implementors to implement it.

It is clear that any form of such layout should use static positioning.

I think that flow:grid (that I am still working on) appears
closer to the goals above than anything else. Actually Jonathan's idea
is very close to the flow:grid - at least it requires minimal number of
changes (attributes/values) to be added to CSS. So I think this is a 
right direction if two persons came to it independently.

I think that the only major thing that is missed in flow:grid is
ability to define "negative" cell positions - cell coordinates relative 
to right/bottom of the table.

Consider this typical web page layout:

| .Header                  |      |
|----|---------------------|      |
|.LSB| Some text here      | .RSB |
|    |---------------------|      |
|    ....                         |
|    |---------------------|      |
|    | Some other lorem    |      |
|    | ipsum here          |      |
|--------------------------|------|
      | .Footer                    |

It can be defined by following styling:

body { flow:grid; }
.header { top: 1#; left:1#; right:-2#; }
.footer { top: -1#; left:2#; right:-1#; }
.LSB    { top: 2#; left:1#; bottom:-2#; }
.RSB    { top: 1#; left:-1#; bottom:-2#; }


So if you have something like this
<body>
   <div .header>Header</div>
   <div .footer>Header</div>
   <div .LSB>left side bar</div>
   <div .RSB>right side bar</div>
   <p>Content #1</p>
   <p>Content #2</p>
   .......
   <p>Content #N</p>
</body>

It will replace elements as you would expect, no matter how
many DOM elements that <body> will get. So the whole
setup is stable to DOM changes.

Needless to say that such layout shall use other existing
CSS attributes. E.g. border-spacing on body may define
minimal value of inter cell spacing. As 'margin's of particular
elements. Currently I use collapsing of cell margins in both directions:
vertical and horizontal in flow:grid.

Grid Positioning Module you have mentioned appears as too 
complex/invasive (at least for myself). It introduces (or reinterprets) 
pretty large number of new attributes like: grid-columns, grid-rows, 
columns, rows(?), column-gap, float-offset, etc.


-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Monday, 16 March 2009 03:20:21 UTC