Re: layout idea

On Sun, Mar 15, 2009 at 10:19 PM, Andrew Fedoniouk
<news@terrainformatica.com> wrote:
> Tab Atkins Jr. wrote:
>> 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.

Makes sense.  I freely admit that the computation steps, and where
various length units fit into them, is still effectively voodoo for
me, unfortunately.

> 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.

Can you give a decent example of where this would fail?  I'm not
understanding what you mean.  Specifically, I don't understand how ad
injection would ruin this layout.  The ads will presumably be injected
into a container which is placed somewhere on the page.  This
container can be selected and then positioned in the normal way.

Worst case, just replace one of the slot names (probably the e in the
center) with @ so it'll swallow any stray elements.

> 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.

This can already be accomplished in the existing layout modules.

Using template layout:

display:
  "ab" /intrinsic
  "@@" /*
  "cd" /intrinsic;

Using Grid Positioning:

body { grid-columns: * *; }
.cell { display: inline-block; width: 1gr; }


> 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.

You can use container elements, you know.  Just position the
containers in the grid, and their contents will fill up the slots
appropriately.  Most of the time these will be natural within your
markup.  The common case where there *isn't* a natural container is
when you have just "all other content" that needs to go somewhere
'natural'.  Both Template Layout and Grid Positioning can handle that
fine, as I illustrated above.

> 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.

Grid Positioning only adds two properties, grid-columns and grid-rows,
and then clarifies how a few existing HTML and CSS constructs produce
a 'natural grid' and how the gr unit can be used within a few existing
properties to mesh with both explicit and natural grids.

~TJ

Received on Monday, 16 March 2009 12:50:00 UTC