W3C home > Mailing lists > Public > www-style@w3.org > March 2009

Re: layout idea

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Thu, 19 Mar 2009 16:04:04 -0700
Message-ID: <49C2CF64.8090408@terrainformatica.com>
To: Bert Bos <bert@w3.org>
CC: www-style@w3.org
Bert Bos wrote:
> On Friday 13 March 2009, Jonathan Snook 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
>> Good or bad, I look forward to some feedback.
> Interesting idea, and well presented.
> I thought a bit in the past about using numerical coordinates (x,y) 
> instead of letters in the Template Layout module, because coordinates 
> are, after all, the first thing you think of when you need to put 
> something in a matrix. But I decided I preferred the letters:
>   + letters are shorter (one letter vs two digits and a separator)
The coolest thing about the template layout is that it is very 
The major problems we have with flow:grid is that it causes problems for 
developers (a.k.a. humans)
to build a mental model of the grid using top/left/right/bottom attributes.
>   - but only a limited supply of letters (up to a few thousand if you
>     read Chinese)
That could be solved by allowing white spaces to be cell name separators

flow: "t1 t1 t2"
"m1 m1 m1"
"b1 b2 b2";

>   + easy to add a row or column, no need to renumber
>   + can reserve a "magic" letter (@) for the default slot
BTW: you have a statement "A template without any letter or @ is 
I think this can be relaxed easily by adding implicit end row at the end:
flow: "t1 t1 t2"
"m1 m1 m1"
"b1 b2 b2"
"@ @ @";
if there is no '@' found.
>   + accidentally overlapping slots is impossible
+ That is definitely a good thing.
>   + possibility in the future of non-rectangular slots
>   + no need to count
>   + can change the layout by changing just the matrix, no need to change
>     the 'position' properties on other elements (useful in combination
>     with Media Queries)
>   + easier to combine with the '::slot()' pseudo-element
> Defining matrices explicitly rather than implicitly (as in your 
> proposal) has advantages, too, because it provides a place to put 
> information about the matrix:
>   + how many rows and columns are there (implicit in your case, which
>     may be an advantage as well as a problem, e.g., for understanding
>     the style sheet)
>   + what is the height and width of slots (your syntax allows multiple
>     conflicting widths and heights, even impossible ones)
>   + any (re)sizing policies, fixed, flexible, levels of flexibility,
>     percentage size... (not sure what your system allows)
>   + self-documenting: the "ASCII art" serves as a diagram of the
>     intended layout (some people do not like this, not sure why)
>   + another magic letter (.) documents explicitly unused slots
> Attaching a matrix to an element also allows a variation: attaching a 
> matrix to an @page rule. In paged media you can thus have matrices that 
> are the size of a page and repeat on each page.
I am going to give a try to template with following assumptions:
1) template is defined by flow: property.
2) as this is going to be strictly position:static so only immediate 
children of the template
can be replaced by template.
3) Placement of the element (immediate child) in layout will be defined 
by float: "name"
as anyway floats and templates are mutually exclusive and the 'float' is 
conceptually close to what
will happen with the element.
4) dimensions and margins will be defined by elements themselves as I do 
have flex units already
so this will work. Margin collapsing for the cells will be made in both 
directions : vertical and horizontal.

Andrew Fedoniouk.

Received on Thursday, 19 March 2009 23:04:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:25 UTC