W3C home > Mailing lists > Public > www-style@w3.org > March 2009

Re: layout idea

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 20 Mar 2009 17:50:52 -0500
Message-ID: <dd0fbad0903201550o53c61acl1974875da6fec9fb@mail.gmail.com>
To: David Hyatt <hyatt@apple.com>
Cc: Brad Kemper <brad.kemper@gmail.com>, Jonathan Snook <jonathan.snook@gmail.com>, "www-style@w3.org" <www-style@w3.org>
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".

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

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:34:24 UTC