Template Layout, implementation, some comments. Was: Re: layout idea

Please see below:

Andrew Fedoniouk wrote:
> Bert Bos wrote:
>> On Friday 13 March 2009, Jonathan Snook wrote:
>>  
...
>>
>> 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 
> illustrative.
> 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 
> illegal".
> 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.
> 

Here is a screenshot of the Template Layout in action:

http://www.terrainformatica.com/w3/template-layout.png

Markup is straightforward:
<ul>
   <li> 1 </li>
   <li> 2 </li>
   <li> 3 </li>
   <li> 4 </li>
</ul>

Styling is:

   ul {
         padding:0;
         border-spacing:-1px;
         flow: "a a"
               "b c"
               "d c";
         width:*;
         height:*;
      }
   li { display:block;
        border:1px solid;
        width:*; height:*; /* flexes, a.k.a. shrink-to-fit */ }

   li:nth-child(1) { float:"a"; }
   li:nth-child(2) { float:"b"; }
   li:nth-child(3) { float:"c"; }
   li:nth-child(4) { float:"d"; }

Some notes about issues that arose while implementing it:

The most non-trivial part was implementation of parsing of the template.
Not parsing per se but handling of border cases. Say, it is not clear 
what this means:
    flow: "a a"
          "b c"
          "d a";  ?
"a" area is not continuous here. Error handling should be clearly 
defined by the specification.
I propose for now to declare that each named area shall be a)
of rectangular shape and b) unique and so continuous.
I propose to drop '@' feature completely, instead to declare following:
All immediate children of the container-template that have no float:"XX" 
defined are replaced as they occupy single row that is appended to the 
main grid. Easy to implement and quite predictable.

And I'd like to note again that flex units are highly desirable in such
cases.

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Friday, 20 March 2009 05:15:06 UTC