- From: David Hyatt <hyatt@apple.com>
- Date: Fri, 20 Mar 2009 15:08:24 -0500
- To: Brad Kemper <brad.kemper@gmail.com>
- 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>
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 UTC