Re: layout idea

On Mar 18, 2009, at 5:52 PM, Tab Atkins Jr. wrote:

> Dave:  You're basically exactly duplicating Grid Positioning, property
> for property.  You have, however, added a few more very useful
> pseudo-elements (::table-row, ::table-cell, presumably
> ::table-column).
>
> I'm cool with merging this into the table model.  Tables have a *lot*
> going for them, because they actually have a flow.

Me too. And the UAs have already solved (or have a way of dealing  
with) various problems regarding tables, and would not have to have a  
separate effort of solving similar problems for grids.

> Grid Positioning,
> by itself, doesn't, which limits its usefulness somewhat.
>
> However, I'm against the rows/cols units.  Grid Positioning currently
> abstracts that into the gr unit, which is useful because you can then
> use it on multicol elements as well.  There's no reason to limit this
> abstraction to only one display type.

Do you mean for moving cells and rows out of source order? Im not sure  
the grid syntax would work that well here, as applying them to "left"  
and "right" does not seem natural, nor does position:absolute on the  
table-cells or rows. In my earlier e-mail, I had this:

  col#:3;

to indicate that the table-cell would be moved horizontally to the  
third column. Numbers bigger than the number of columns set on the  
table would be invalid and/or ignored.

Thus, if you started out with a 5 column table (with the number of  
columns set in the table style), and you moved the cell from column 1  
into column 3, then cell 2 of that row would move into column 1 and  
cell 3 would move into column 2. Thus, not two cells occupying the  
same slot. Conflicting col# rules would be resolved by the last rule  
winning, with any cell placements up until that point moving out of  
the way into the next available adjacent slot (including slots in the  
next row, if you run out of columns in the current row).

The row# property would act similarly in the vertical direction, with  
new anonymous rows being created if neccesary (since row creation  
would be dynamic in this model). By the way, I think that if you  
specified the number of rows, it would act more like a minimum number,  
as new rows would be created to accommodate all the items in the table  
that are table-cell or table-row.

I think 'row#' and 'col#' would be very easy to understand. The author  
could specify one or both, and other cells would move to get out of  
the way or close holes left by the movement.

> I originally thought we could even kill the table-row-span and
> table-column-span properties and replace them with height/width in gr
> units, but we can't.  Using a width/height affects, well, the
> width/height of *that cell* (and the row/column the cell is in), but
> rowspan and colspan affect the table's actual *flow*.

I wonder if we need the word 'table-' in there, and if we actually  
need to spell out 'column', or if 'row-span' and col-span' is enough  
(like the HTML properties, with a dash added for CSSiness). In theory,  
the same properties could then be used for other things, so that if I  
change the display type and add columns (for multi-column layout),  
then col-span could maybe be used with that too. By the same notion, I  
would replace table-columns with just 'columns' (or to 'column-count'  
if you don't want to change the shorthand meaning of 'columns' in  
multi-column layout).

> Questions!
>
> 1) How does this interact with implicit table creation?  Frex, given
> this markup:
>
> <style>
> body {
>  display: table;
>  table-columns: 4;
> }
>
> div {
>  display: table-cell;
> }
> </style>
> <body>
> <div>foo</div>
> <div>bar</div>
> <div>baz</div>
> </body>
>
> What do we see?  I expect this:
> +-----+-----+-----+-----+
> | foo | bar | baz |     |
> +-----+-----+-----+-----+
>
> That is, I expect display:table-cell to shift content into the
> table-flow of the parent element, and for the parent element's
> explicit row/column declarations to be honored.

Yes, exactly, except that I would like to see baz automatically  
becoming col-span:2 so that the row has the required number of cells.  
In fact, I would like to have something like that for rule 7 of  
section 17.2.1 of CSS21 tables [1]. Its a little beside the point, but  
anything that generated cells for a cell-free row, should really end  
up with all of its columns filled.

> 2) Same markup as (1), except this time table-columns is set to 3, and
> there are four <div>s.
>
> I'm hoping for:
> +-----+-----+-----+
> | foo | bar | baz |
> +-----+-----+-----+
> | qux |     |     |
> +-----+-----+-----+
>
> That is, once again, a table's explicit row/column declaration is
> honored *first*, and display:table-cell elements are positioned as
> necessary in this flow.  Removing the table-columns declaration (or
> setting it to table-columns:auto) would create a 1x4 table instead, as
> the CSS table model would normally do.

Exactly what I had in mind, plus a col-span on qux so that the last  
row has enough columns in it. Note how a new row was created  
automatically. Thus, if you specify a number for the rows, it would  
really be a minimum, with possible rows of empty cells (or empty col- 
spanning cells).

> This would allow for a very nice gridding of linear data.  It's imilar
> to a horizontal multicol element filled with inline-blocks, except
> with explicit column control.
>
> 3) Can table-row-span and table-column-span be set on a ::table-cell()
> pseudoelement?
>
> That is, I want to duplicate:
> <table>
>  <tr>
>    <td colspan=2></td>
>  </tr>
>  <tr>
>    <td></td>
>    <td></td>
>  </tr>
> </table>
>
> With the following:
> <style>
> body {
>  display: table;
>  table-rows: 2;
>  table-columns: 2;
> }
>
> body::table-cell(1,1) {
>  table-column-span: 2;
> }
> </style>

Yes. I like it.

> 4) Same markup as (3).  Assuming that it works, what happens to
> ::table-cell(1,2)?

By my way of thinking, it instantly becomes ::table-cell(2,1), due to  
the col-span of the above (it moves to the next available slot).

> Can I use it?  Is it invalid?  Is it treated as
> the same cell as ::table-cell(1,1)?  What if I set rules on it earlier
> in the source, before it was specified that ::table-cell(1,1) should
> span 2 columns?

Good questions. There would be an order to follow.

> What if I told ::table-cell(1,2) to span two columns
> as well?

It would end up spanning the second row. On the other hand, if you put  
a colspan on the cell that would finally be last cell of a row, then  
its a little dicier. Either do what TABLE HTML elements do in that  
case, or ignore it unless some other moved cell or col-span knocks it  
into a new row. I'd prefer the latter, so that the number of columns  
specified remain true. Note that if we went that way, then col-span: 
100000000 would probably be the same as col-span:all-remaining. I  
would actually kind of like to have something like col-span:remaining,  
col-span:remaining(-1), col-span:remaining(-2), etc. That would be  
useful (also for row-spans).

> 5) Given an element with display:table, what happens to its children
> *without* display:table-cell?

Follow the rules for generating anonymous table-* elements around them  
(such as rules 5-7)[1], while maintaining the specified number of  
columns.

> Currently, the CSS table module says that it all gets wrapped into an
> anonymous table-row-group/table-row/table-cell blocks, broken up into
> multiple such blocks if there are display:table-* elements mixed in.
>
> This doesn't seem to mix well with your idea of moving things into
> particular cells with the table-position property.  They already exist
> in a table cell, and even if you move them all out, you've still got
> an empty anonymous table-cell block sitting there ruining your layout.
>
> After a bit of thought, the cleanest solution seems to be to specify
> that the auto-wrapping *only* happens to elements with a
> table-position set to the initial value.  If they have anything else,
> they're ignored and positioned after the table is done being laid out.
> That prevents the creation of anonymous table-cells when you don't
> want them, but lets you still create anonymous table-cells when you
> *do* want them.

I'm not sure I follow you, but it may be because of what I imagine  
happens to the cell at the location that another cell is being moved  
to (it and the cells after it slide to the right one slot, wrapping  
into new rows if needed, or they move to the left if the cell that was  
moved creates an empty grid slot to the left).

Another question is what happens if there is one or more elements  
already with display:table-row on them, and the number of cells in it  
are more than what's specified on the main table element. I'd say the  
table takes precedence, and something gets moved to a new row. But  
that is open to debate, I suppose.


>
>
>
> Erm, this is rather long, so I think I'll stop with the questions  
> for now.  ^_^
>
> ~TJ


[1] http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes

Received on Thursday, 19 March 2009 06:02:40 UTC