Re: layout idea

On Mar 19, 2009, at 10: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.  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.
>
> 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?
>

Assuming no cells have been encountered yet....

(a) If #foo and #bar are table cells, then there is a conflict, and we  
need to decide what would happen.  I'd be inclined not to allow two  
cells to occupy the same position, but then we have to decide what to  
do when an invalid position is specified.

(b) If #foo is a table cell and #bar is just a block, then #bar would  
be placed inside #foo.

(c) if #foo is a block and #bar is a table cell, then #foo would be  
placed inside an anonymous cell at (2,2).  #bar would then cause a  
conflict as in example (a).

(d) If both objects are blocks, then they would both get put inside an  
anonymous cell at (2,2).

I think the model should encourage not specifying display:table-cell  
cells at all.... i.e., objects that specify table-position should  
commonly just be blocks not cells.

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