Re: layout idea

On Mar 19, 2009, at 8:15 AM, Jonathan Snook wrote:

>> TDs in HTML cannot be overflowed, as they automatically grow to  
>> contain their contents. If table-cells don't already act the same  
>> way, they really should (as Andrew also mentions).
>
> And if that's the way we want to define it, I'm fine with that.

I should have said that this is assuming the default 'table- 
layout:auto', and not 'table-layout: fixed'.

> So, if you have two static or relative elements pointed to the same  
> cell, do they stack or overlap? What if they have differing spans?  
> HTML source order wins or CSS source order wins?

Assuming you are talking about to items that are display:table-cell,  
for instance, there would be only one per cell position. When you give  
a new cell position, you are changing the order, not putting two  
things into the same position (and whether static or relative doesn't  
matter). At least that is how I would do it. If you are not talking  
about a table-cell (or table-row in some cases), then you must be  
talking about absolutely positioned item, which is out of flow.

> Example:
> <div id="a"></div>
> <div id="b"></div>
>
> #b { table-position: cell(1,2); table-col-span: 2; height:50px; }
> #a { table-position: cell(1,1); height: 100px; }
>
> What's the height and width of either container and what goes where?


If #a and #b are both 'display:table-cell', and the numbers of cell()  
are 'cell(<row-position>,<column-position>)' (which I don't think is  
obvious), then here is how I think that would be handled:

1. #b { table-position: cell(1,2);} puts #b's position into the second  
column of the first row, same as sort order.

2. #b { table-col-span: 2; } means that you are trying to span across  
a column that is not there already, and you did not specify a number  
of columns in the table, so it is debatable what should happen here.  
But lets assume it creates a new column. So now #b is in columns 2 and  
3, and the row-height is currently a minimum of 50px.

3. #a { table-position: cell(1,1); } didn't change anything, because  
the sourse order would have given you that.

4. #a { height: 100px; } sets the minimum row height to 100px.

End result: You have one row with 3 columns, with #a in column 1, and  
#b in columns 2 and 3. All cells are 100px (could grow taller if they  
had content, but in this example they don't).

> Throw in a floated image that exceeds 50px in #b and then what do  
> you get?

Same as if you float a 50px+ tall image inside a <TD height="50">  
today that is next to a <TD height="100">.

> My opinion: #b would stretch to 100px (highest value wins). But I'm  
> still not sure if you would stack these or overlap them, since  
> they're both static.

Stack or overlap what? The cells? No, they would not occupy the same  
spot. They are just reordered with every 'table-position' assignment.  
And with every new 'table-position' assignment or rowspan or colspan  
assignment, cells could be rewrapped to a new row. Without any  
explicit row elements, the UA would:

1. do all the spans and re-ordering of column positions in order as  
though there was just one row, then

2. if there is a column-count (or whatever its called) on the table  
then it wrap the cells to new rows to honor that (limiting col-spans  
to what would fit in the specified number of columns), then

3. if the is a row-count (or whatever its called) on the table then  
add anonymous rows and cells if necessary to have that many rows as a  
minimum.

> I flip-flop in which approach is better but I still feel that using  
> "position: cell", while less flexible, removes plenty of edge cases,  
> and could allow overflow.
>
> -js
>
>

Received on Thursday, 19 March 2009 16:25:32 UTC