Re: layout idea

On Mar 20, 2009, at 5:02 PM, Tab Atkins Jr. wrote:

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

I disagree.  I would expect the first cell to get the slot and later  
cells to get displaced.  Think about incremental rendering.  You want  
the earlier cells to win, not have everything popping all over the  
place as later cells suddenly displaced the earlier ones.

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

Really I'd like to see an example that proves this is needed.  It adds  
complexity that it would be nice to avoid if nobody can prove that  
it's really needed.

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

That's almost a separate problem.  There's no way to refer to  
anonymous cells/rows/columns etc. now, and it's already an annoying  
issue.

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

I disagree (as I said above).  You want clean incremental rendering,  
which means slots should be first come first serve.

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

Yeah if you have extra explicit rows that then specify more columns  
than the original grid did, you have to decide whether intelligent  
fitting algorithm will adjust because new columns have been added.   
That's tricky.

dave
(hyatt@apple.com)

Received on Friday, 20 March 2009 22:31:02 UTC