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

Re: layout idea

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Fri, 20 Mar 2009 13:36:59 -0700
Message-ID: <49C3FE6B.8080507@terrainformatica.com>
To: David Hyatt <hyatt@apple.com>
CC: Brad Kemper <brad.kemper@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Jonathan Snook <jonathan.snook@gmail.com>, "www-style@w3.org" <www-style@w3.org>
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.

-- 
Andrew Fedoniouk.

http://terrainformatica.com
Received on Friday, 20 March 2009 20:37:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:17 GMT