Re: layout idea

On Fri, Mar 20, 2009 at 5:30 PM, David Hyatt <hyatt@apple.com> wrote:
> On Mar 20, 2009, at 5:02 PM, Tab Atkins Jr. wrote:
>> 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.

That would be why I said we can skip it for now.  ^_^  I do think it's
important, but I want to solve it *correctly*, and I don't want to be
forced to do that here.

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

Indeed, so it's not a layout issue *per se*.  Something intelligent
does have to be done about this, though.

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

You can't save incremental rendering when you're rearranging a table
no matter *what* you do.  If the first cell wins, as you want, then
the second cell has to go *somewhere*.  It either slides in to the
right of the first cell, in which case the *existing* rightward
neighbors of the first cell get shoved, borking incremental rendering,
or it goes to the first empty hole, which completely ruins the
source-order-independence ideal.

If we want to keep source-order independence, I don't think it's
possible to keep incremental rendering without some
possibly-significant reflows.  If this is absolutely important, then
we can probably just stop right here, add row-span and col-span, and
then look for a layout manager that *does* allow incremental rendering
while preserving source-order independence.

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

Well, what's the intelligent fitting algorithm you've got in mind?
Currently in my head it's just "act like tables".

~TJ

Received on Friday, 20 March 2009 22:51:28 UTC