Re: layout idea

On Mar 19, 2009, at 12:39 PM, Brad Kemper wrote:

>
> On Mar 19, 2009, at 8:21 AM, Tab Atkins Jr. wrote:
>
>> On Thu, Mar 19, 2009 at 1:01 AM, Brad Kemper  
>> <brad.kemper@gmail.com> wrote:
>>> I think 'row#' and 'col#' would be very easy to understand. The  
>>> author could
>>> specify one or both, and other cells would move to get out of the  
>>> way or
>>> close holes left by the movement.
>>
>> Ah, no, I was talking about out-of-flow alignment.
>
> I do not think moving a cell or row should put it out of flow, and I  
> did not interpret what David Hyatt said to mean that either. He did  
> mention extending position:absolute to align __content__ of a cell  
> to particular cell boundaries.
>

That's correct.  table-position was intended for in-flow placement  
into the grid.  position:absolute with grid units would be for out-of- 
flow placement.

>> In out-of-flow,
>> grid units are ideal, as they provide a simple and useful abstraction
>> that trivially generalizes to allow intuitive out-of-flow alignment  
>> on
>> other flow models as well, such as multicol.
>
> I disagree. I do not think taking a table cell (or table cell-like  
> structure) out of flow is simple or trivial. Most layouts are based  
> on a grid, and it is much simpler to maintain a grid when things are  
> in flow. Out of flow, by definition, means that the item is no  
> longer there to affect the height of its neighbors, and there is  
> nothing to prevent important content from being covered. Most  
> layouts would not want that. If you do want to take something out of  
> flow and position it in a place where it can cover up important  
> content, you can position DIVs etc that are contents of a cell.
>
>> In-flow positioning is a bit more difficult.  What happens in the  
>> following?:
>>
>> #foo {
>> row#: 2;
>> col#: 2;
>> }
>>
>> #bar {
>> row#: 2;
>> col#: 2;
>> }
>>
>> Do they overlap?  Does one slide into place, and then bump the other
>> one out?  If so, which?  And in which direction? (Presumably to the
>> right.)  Is one of the declarations invalid?
>
> How many columns have you set on the element acting as the table?  
> Let's assume that you set it to have 2 columns. The first rule would  
> put #foo into the bottom right corner, with the other cells  
> currently empty. The second rule overrides that and says, "no, #bar  
> should go there. So #foo moves to the next available slot, which  
> would be row 3, column 1 (I would not put it into the empty slots,  
> as they were not created as the result of #bar bumping #foo out of  
> its way). If you did not have column counts set on the table, then   
> #foo would either move to column 3 or row 2, or we could say that  
> new columns cannot be created that way, and it would move to row 3  
> column 1.
>
> I find this very simple and consistent, with much fewer issues to be  
> resolved than with out-of-flow cells.
>

Yeah, we'll have to work out what to do with conflicts... i.e., where  
the new cell goes.

>>>
>
> A little off-topic, but if I turned a large paragraph into table- 
> row, I would hope for it to fill the row, not just some small square  
> at the beginning of the row. But ayway, I think having something  
> like 'table-col-span: remaining' could take care of that and provide  
> the option for current behavior. Maybe 'max' would be a better word  
> than 'remaining'?
>

table-col-span: *

would be my preference to just say something spans to the end of the  
table.

>>
>> Well, we've got two different ways of pushing content around in table
>> flow, which David touched on.  We can move a block around as a
>> first-class table flow entity, or we can flow contents *into*
>> table-cells, where they then take place in whatever flow model the
>> table-cell has set for itself.
>
> No. We don't flow contents *into* cells. We *absolutely position*  
> contents to align with edges of particular cells.
>

Three kinds of positioning:

(1) table-position on a display:table-cell.  The object actually  
becomes the cell at that position.  A pseudo-element can't refer to  
this cell position when this is done.
(2) table-position on a normal flow object like a block.  The object  
is placed *into* the cell at that position.  If no cell exists at that  
position, then an anonymous one gets made.  A pseudo element can be  
used to style this cell.
(3) position:absolute with grid units.  Provides out of flow alignment  
to cells in tables.

Received on Thursday, 19 March 2009 19:40:17 UTC