Re: layout idea

David Hyatt wrote:
> On Mar 18, 2009, at 12:25 PM, Jonathan Snook wrote:
> 
>>
>> On 16-Mar-09, at 4:01 PM, Bert Bos wrote:
>>> + accidentally overlapping slots is impossible
>>
>> I don't think we can ever stop people from making mistakes and being 
>> able to overlap slots is, to me, a handy feature.
>>
>>> + what is the height and width of slots (your syntax allows multiple
>>>   conflicting widths and heights, even impossible ones)
>>
>> This is the case with tables, as well, which is something I tried to 
>> mimic as I felt it'd be easier for people to grasp (at least for those 
>> who've done table-based layouts) and easier for implementors (since 
>> this logic is already in place for tables).
>>
>>> + self-documenting: the "ASCII art" serves as a diagram of the
>>>   intended layout (some people do not like this, not sure why)
>>
>> The biggest dilemma with this is just spaces vs tabs and trying to 
>> maintain "ASCII art". (Somehow I see bloggers dedicating whole 
>> articles just on best practices for this.)
>>
>> My reason for putting together Matrix Layout was not because I felt it 
>> was a better implementation that solved all problems but because it 
>> was a simple implementation based heavily on existing concepts that 
>> would make it easier for implementors to build sooner rather than 
>> later. Dave Hyatt's recommendation of extending the Grid Module has 
>> made increasing sense to me and I have no major complaints with that 
>> solution, either.
> 
> I was pointed to:
> 
> http://meyerweb.com/eric/thoughts/2009/02/17/wanted-layout-system/
> 
> I agree with most of what Eric says, although I believe he may be 
> condemning table layout too quickly (after all, table layout could be 
> extended dramatically).
> 
> Here are my high-level thoughts about a better layout system:
> 
> (1) We really need to pick a single proposal and run with it.  Right now 
> we have table layout, Template Positioning, Grid Layout, Matrix Layout, 
> Andrew's grid flow, and - although it hasn't been written up yet - the 
> XUL flexbox grid.  These layout systems all define objects with rows and 
> columns and spanning cells.  Some of them have more capabilities than 
> others, etc., but they're all really similar.  The question we have to 
> ask is: which one do we use?
> 
> (2) A grid should be a normal flow construct.  Positioning objects that 
> snap to a particular row/column position while still being out of flow 
> and not affecting the layout of the grid itself should be possible.
> 
> (3) Spans should be supported on cells in the grid.
> 
> (4) It should be possible to put objects in slots in the grid and have 
> them be part of the grid's flow (i.e., not positioned out of flow).  
> This could be done by saying the object itself *is* the cell, or by 
> saying the object goes *into* a cell.  "Source order independence."
> 
> I think it would be a worthwhile exercise to examine whether or not 
> table layout itself could be extended to have all of these features.  I 
> know Eric Meyer was quick to condemn it, but I believe he's thinking of 
> table layout as it works today.  Let's imagine we could extend it:
> 
> (a) Add row-span and column-span to CSS.  This is trivial to define and 
> to implement.  We can make it so that cells can have spans when defined 
> in CSS.
> (b) Add row-position and column-position to CSS.  I see no reason why 
> this should not be possible.  We'd have to figure out if it was table 
> section relative or whole-table relative.  I'd say probably the former.  
> It would probably be easiest for this to apply to objects with display: 
> table-cell only, but you could also imagine creating an anonymous table 
> cell at that position if none existed yet.
> (c) Add table row/column units to left/top for positioning objects 
> relative to a specific cell.
> (d) If table layout has some limitations (for example vertical flexing 
> like XUL grids can do), that could always be solved with a new value of 
> the table-layout property.
> 
> I guess I'm wondering if anyone has given much thought to extending 
> table layout to *be* a grid system like this, and if there are any 
> obvious problems with such an idea.  To me it looks completely possible, 
> and also has the advantage of building on existing implementations in 
> every modern browser.
> 
> dave
> (hyatt@apple.com)
> 
> 

Dave, I guess that table layout here is display:table and friends.

Adding of just @col-span and @row-span to CSS is far not enough.

To be able to reproduce <table>s in full CSS should have:
  1) flex units, that is a must.
  2) overflow:never[ or none]; or min-width:min-content-width / 
min-intrinsic, same for height.

Without these <table> is non-beatable by CSS for layout purposes.

While consider various options we should keep in mind that there
are and will be other useful layout schema's other than the grid.
So I think it has to be @flow attribute or something that allow to 
define layout manager.

So far I have these LMs:
   flow:horizontal - all elements replaced in single row with
        vertical flexes computed against row height. So you can
        define that all elements will have same height equal to
        tallest element in the row. Horizontal flexes computed
        against width of the container.
   flow:horizontal-flow - pretty much the same as above but
        elements are being replaced in multiple rows. Existing
        @clear allows to break rows explicitly. Think about bricks
        in the wall, that is it.
   flow:vertical-flow - like above but elements replaced in
        multiple columns.
   flow:vertical - that is pretty much what <div> is using now for
        layout of its child blocks.
   flow:grid - that is what I was talking about before.

So as you can see grid/table layout is just one of many layout
managers[1]. I think it would be wise to dedicate special attribute
to it.

And yet about table layout and col/row-spans.
<table>s have simple but limited algorithm of calculating constraints
that spanned cells apply to spanned rows/columns. That algorithm 
probably needs to be revised. But in any case, even for display:table
existence of flex units[2] is crucial.

And I am yet silent about flex usefulness in animations. Here is an 
example: 
http://terrainformatica.com/htmlayout/images/animation-slide-bar.jpg
Expanded section there has height:100%%; spanning all available vertical 
space in the container. So expanding/collapsing animations are trivial - 
from 0%% to 100%% on expanding and from 100%% to 0%% on collapsing.


[1] http://java.sun.com/docs/books/tutorial/uiswing/layout/visual.html
[2] http://www.terrainformatica.com/htmlayout/fspu.whtm


-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Thursday, 19 March 2009 04:15:16 UTC