Re: layout idea

David Hyatt wrote:
> On Mar 20, 2009, at 3:36 PM, Andrew Fedoniouk wrote:
> 
>> David Hyatt wrote:
>>> On Mar 19, 2009, at 8:41 PM, Brad Kemper wrote:
>>>
>>>>
>>>>
>>>> On Thu, Mar 19, 2009 at 5:31 PM, Tab Atkins Jr. 
>>>> <jackalmage@gmail.com <mailto:jackalmage@gmail.com>> wrote:
>>>>
>>>>    In (b), you say that display:table-cell elements are 'tacked on' to
>>>>    the structure produced implicitly by table-rows and table-columns.
>>>>    So, given this markup:
>>>>
>>>>    <style>
>>>>    body {
>>>>     display: table;
>>>>     table-rows: 2;
>>>>    }
>>>>
>>>>    .cell {
>>>>     display: table-cell;
>>>>    }
>>>>    </style>
>>>>    <body>
>>>>     <div ..cell />
>>>>     <div .cell />
>>>>    </body>
>>>>
>>>>    Would you expect a three-row table, with the first two rows being
>>>>    anonymous rows created implicitly by the table-rows:2
>>>>    declaration, and
>>>>    the third being an anonymous row generated around the <div .cell>
>>>>    blocks?
>>>>
>>>> Oh, I really hope not. I would hope they would flow into the first 
>>>> row, and that if you wanted something that was only one column wide 
>>>> that you would put table-columns:1 into the body (thus forcing the 
>>>> second div into the second row).
>>>>
>>>
>>> It was more a question of whether or not people would want to use 
>>> table-rows/table-columns and still retain the original grid fitting 
>>> behavior.  For example, table-columns by itself is a convenient 
>>> shorthand to just avoid declaring some <col> elements.  If you use it 
>>> and not table rows, you haven't necessarily made a grid.... i.e., 
>>> what about that property has indicated that there should be some kind 
>>> of intelligent grid fitting?  Nothing.  That was really my 
>>> concern.... the idea of fitting isn't really implied by a 
>>> table-columns property (it probably is somewhat implied by a 
>>> table-rows property though).
>>>
>>> Maybe the solution is to just have a single property that represents 
>>> both... e.g., table-grid.  Then the idea that fitting should occur by 
>>> default might be more natural.
>>>
>>>>
>>>>    I like table-position:fit.  It keeps us closer to the table model as
>>>>    it exists now, and puts the burden on wrapping or extending on the
>>>>    individual cells.  Good call.
>>>>
>>>> I don't really understand that. It seems to be making it more 
>>>> complicated than necessary. It seems to me that if you put 
>>>> table-columns:n into the display:table parent element, then that 
>>>> means you want all the display:table-cell children to conform to a 
>>>> grid that is n columns wide. If no table-columns number is 
>>>> specified, and there are no child elements that have 
>>>> display:table-row set on them, then you will have all your 
>>>> table-cells in one row, and any other rows you create via 
>>>> 'table-rows' would have empty cells.
>>>
>>> I don't really think table-columns by itself necessarily implies 
>>> this.  If I declare <col> elements in my HTML, I haven't implied any 
>>> intelligent grid fitting behavior, even though they have all the same 
>>> information as the table-columns property does.  If we think 
>>> specification of rows/cols in CSS should imply this, then I think we 
>>> should change how the grid is declared.
>>>
>>>>
>>>>
>>>>    > We pretty much agree, except I want the initial value to be
>>>>    "the way things work today" and to have a new value for
>>>>    table-position to get the fitting behavior we all like.
>>>>
>>>>    Cool, and I like the idea of table-position:fit.
>>>>
>>>> Not me. It seems totally unnecessary.
>>>>
>>>
>>> I agree that I don't really ever see a need to make a grid and then 
>>> not snap cells to it.  The issue is that table-columns by itself 
>>> doesn't imply that you made a grid.  So I think we just need a better 
>>> way of specifying the grid.
>>>
>>> dave
>>> (hyatt@apple.com <mailto:hyatt@apple.com>)
>>>
>> <table> works pretty well already for tabular data.
>> There is a need for layout managers of different types (grid alike LM 
>> is just one of them) .
>> I do not think that it makes real sense to try to fit all possible 
>> cases into that display:table.
>>
>> Consider these four elements:
>>
>> |--- 100px---|-----------1* ----------|
>> |-------2* -----------|------ 1* -----|
>>
>> where elements replaced into two rows. In each row elements have the 
>> same height equal to tallest element
>> and some elements have flex widths (and heights). There is no way in 
>> current CSS to define this. At all.
>> Neither display:table nor floats will help.
>> I mean trying to make display:table to serve other roles than just 
>> presenting tabular arrangements will
>> make display:table overcomplicated and will not be a complete and 
>> expandable solution anyway.
>>
> 
> CSS3 Flexible Boxes can do this (and are implemented in Gecko and 
> WebKit).  I think some of those solutions can be applied to grid layout 

I assume that "CSS3 Flexible Boxes" means that attempt to marry XUL 
flexes with CSS? How this will be compatible with flex units needed
for say display:table and rest of the CSS? Or this will be a separate
mechanism?

> as well.  But really the way to get different "layout managers" in CSS 
> is with different values of the display property.  In this case (adding 
> on to table), we aren't defining a new kind of layout system.  We're 
> just extending an existing one.

That 'display' property is just "something" to be honest.
It tries to combine different things in the same property.
For now 'display':
1) defines how element is replaced in respect of its siblings and
2) establish layout manager for the content.

These two are different entities.

You may wish to say:

   display: inline[-block];
   flow: horizontal[-row];

First one tells how block itself is replaced and
second one ('flow' that used to be 'display-model') defines
how it will replace its children.

We can try of course to add something like inline-table-row to
the zoo ...

Ideally it should be:

flow     : table | row | grid | column | columns
            | h-flow | v-flow | "template" | etc. ;
display  :inline | block | etc.;

In any case
   display:table-cell
is a technical nonsense. table cell is just a 'block' by any means.

> 
> dave
> (hyatt@apple.com)
> 
> 
> 

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Saturday, 21 March 2009 02:43:41 UTC