Re: layout idea

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

dave
(hyatt@apple.com)

Received on Friday, 20 March 2009 21:18:03 UTC