Re: layout idea

On Thu, Mar 19, 2009 at 8:41 PM, Brad Kemper <brad.kemper@gmail.com> 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).

After some thought, you're right.  Table-cell blocks in the markup
should immediately flow into the table exactly as normal.  This is by
far the simplest and most comprehensible solution.  I think the core
of making this an actual layout manager hinges on intelligent behavior
for displacing table cells when other cells are moved into position.
Your original idea of the later declaration winning and the previous
one being shoved to the side is absolutely the way to go.

There's a few issues we need to settle on.

Flowing blocks into a table cell
--------------------------------
I still believe that supporting flowing blocks into a cell is a
necessary thing to unleash the true power of a layout manager.
However, I'm okay with delaying this for a proper Named Flows module.
There's a lot of idea space here that needs to be properly covered,
and trying to rush it for this module will probably just mean we do it
wrong.  So, chunk this for now.  You want to push something around in
a table module, you can wrap it in a container.  This is a 90%
solution that works for me.

Dealing with automatically generated anonymous table-cell blocks
----------------------------------------------------------------
I'm talking about those generated by the table layout algorithm in the
Tables Module.  If you set an element as display:table and it has
children who don't aren't display:table-*, they'll get wrapped in
cells automatically.  Right now, we have no way to refer to them.  The
question is, do we care?  This is, btw, a big reason to *support*
flowing things into anonymous cells, so then you can name or otherwise
identify these things, but let's pretend that we're not considering
that at all right now.

I'm thinking that we can get away with not caring.  If you want to use
the advanced features of table-layout (reorganizing cells, mainly),
you have to wrap things in an addressable container.  You may not need
to - your source order might give you cells which position themselves
just the way you want.  But if you're not so lucky, tough luck (until
Named Flows exists).  As Brad said, most layouts on the web today
already use containers which would be perfect for this.  I want to end
this practice as much as possible, but I'm willing to wait.

Handling positioning conflicts
------------------------------
That is, what to do when two cells have table-position: 2 2.  The idea
I'm liking right now is last-rule-wins.  If a cell already exists
where you want to move it, it gets bumped into the next column.

Now we must address what do we do if this would increase the number of
columns?  If we stick close to the existing table model, the answer is
"increase the number of columns".  Is this sufficient?  I think so.
The only time I can see it *not* being fine is when you have something
like this:

<div #some-content-blocks>
  <div>blah</div>
  <div>blah</div>
  ...
</div>

You don't know how many content blocks you'll have, you just know that
you want them to look like a table; that is, you want all the blocks
on a particular row to have the same height and the widths to align.

This seems like something Flexible Box can solve by itself, as David
alluded to.  Make #some-content-blocks a table-cell and position it,
possible with a row-span, then use horizontal box flow with a % width
to lay out the individual blocks.  They'll flow sideways, and then
move onto a new line when the current one is full.

So, I think we can just stick with the existing table model there.
Cells absolutely stay on the row they are laid out on, unless you
explicitly move them with table-position, and will increase the column
count if necessary.

Conclusion
==========

Um, I've backed down from a lot of what I wanted, for simplicity and
to prevent an important problem from being solved prematurely.  It
appears only the following properties would have to be defined for me
to be happy:

* row-span
* col-span
* table-position

And the only additional thing that needs to be clarified is what to do
when there is a table-position conflict (I say existing cell gets
shoved to the right).

~TJ

Received on Friday, 20 March 2009 22:03:03 UTC