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

Re: layout idea

From: David Hyatt <hyatt@apple.com>
Date: Fri, 20 Mar 2009 15:08:24 -0500
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Jonathan Snook <jonathan.snook@gmail.com>, "www-style@w3.org" <www-style@w3.org>
Message-id: <6077ABCD-9F74-4B4D-B863-F4ABA6187CB1@apple.com>
To: Brad Kemper <brad.kemper@gmail.com>
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> 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)
Received on Friday, 20 March 2009 20:09:07 GMT

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