Re: layout idea

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.  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.

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*.

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.


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.

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>


4) Same markup as (3).  Assuming that it works, what happens to
::table-cell(1,2)?  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?  What if I told ::table-cell(1,2) to span two columns
as well?

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

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.


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

~TJ

Received on Thursday, 19 March 2009 00:53:34 UTC