- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Sat, 21 Mar 2009 02:31:08 -0700
- To: David Hyatt <hyatt@apple.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Jonathan Snook <jonathan.snook@gmail.com>, "www-style@w3.org" <www-style@w3.org>
- Message-Id: <F5D8E278-B9E6-46C2-9D96-898258DBB34A@gmail.com>
On Mar 20, 2009, at 1:08 PM, 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> 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.
It is we decide that's all it should mean.
> 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).
Well, if specifying table-columns as a property on an object ONLY
replicated what <col> elements could do, then I guess you're right.
But I envisioned something more, a way of having an enforceable number
of columns and NOT get stuck with the bad old situation of the columns
in a row not adding up to what they are in another column or in the
COL elements. I've seen that sad situation in too many sad pages (by
other authors). We have a chance now to have a CSS element that not
only declares the number of columns, but enforces it as an absolute
truth, unlike what simple COLs can do. COL elements cannot create rows
that wrap to new rows, but that is one of the most exciting and
powerful features of what we've been discussing, to me.
I think it would be a shame if when authors declared the number of
columns their table should have, that they could end up with the
number of columns in some rows not matching that number, or not even
being consistent between rows. That's a 'feature' of HTML that I would
not want to replicate, because it is almost always a mistake due to
authors having to keep track of that themselves in the face of
colspans and rowspans.
If I as an author declare that I want my table to have 3 columns, then
I want it to have three columns, no more no less, and I care much more
about that than about matching all the foibles of COL elements. In the
end, it would still create a table structure that could also be
described by HTML tables, and cold also include anonymous table-column
elements that matched the number too.
The number of actual rows many depend on how many cells there are by
the time you get to the end, but breaking to create new rows once
you've filled the number of columns for a row that the author asked
for seems like a simple and clear solution, and I'm guessing would be
more efficient for the UA than going the other way and giving rows
that kind of absolute precedence.
> 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 actually find it much less natural to not try to honor the number of
columns specified, in order to match the limitations of HTML COL
elements. Plus, the author would still have the option of not
specifying a column count on the table, and using a display:table-row
element to group the cells in a more old-skool way.
>> 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.
I don't think <col> implies it, but 'table-columns' or 'column-count'
could. And in the end it really is a table display model, you are just
using a more powerful property to determine where the anonymous rows
go that <col> is able to do on its own.
How about if 'column-count' worked the way I described, and 'table-
col' only replicated what <col> can do? In that case, I think 'column-
count' would get a lot more use from authors (<col> elements are very
nearly useless in my opinion), but I'd be happy enough if we had both.
>> > 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.
I understand now, but this is because you are thinking of them as
exactly replicating what COL elements do. I want them to do that and
more, and see little value in the more limited version.
> So I think we just need a better way of specifying the grid.
I think it should still be display:table, because it still creates a
structure of elements and anonymous elements that exactly replicates a
structure and behavior that you could create with HTML tables, and
makes use of ALL the CSS properties that have already been created for
tables, with all their advantages of aligning all edges to the largest
content, sharing borders, etc. I don't want to re-invent the wheel, if
the end result is indistinguishable from a wheel.
>
> dave
> (hyatt@apple.com)
>
Received on Saturday, 21 March 2009 09:31:47 UTC