Re: starting a new table row

On Jun 17, 2009, at 10:27 AM, Boris Zbarsky wrote:

> Brad Kemper wrote:
>> I dislike having more and more different display values, especially  
>> one that is almost, but not quite, identical to another.  I would  
>> prefer a new value for 'clear' that affected rows instead of  
>> floats. .my_table_structure > div { display: table-cell }
>> .my_table_structure > div:nth-of-type(4n+1) { clear:row; }
>
> This doesn't seem that unreasonable, though it raises the issue of  
> what to do for non-table elements when "clear:row" is set.   
> Presumably it'd just have no effect.

Right (unless the second part, below, was also implemented). If there  
is no applicable table to start a new row in, the "clear:row" would do  
nothing, just as "clear:both" does nothing when there are no floats.

>> Perhaps this sort of clearing could even be applied to an element  
>> in the contents of a table cell, to force its nearest table-cell  
>> ancestor into a new row.
>
> That's much much harder to implement than just allowing it on the  
> table cell, for what it's worth.  I _think_ the table-cell case  
> could be done in a few hours with very little performance cost; the  
> other would take a great deal more time; I can't even speculate as  
> to whether it could be done without performance costs at this point.

I was afraid that might be the case. I was thinking that the existing  
values for clear works somewhat like that, moving through ancestors to  
see the effect they might need to exert on them. But its possible that  
I am a little mixed up about that, as I don't frequently use floats  
and clears for exotic layout effects.

> Are there obvious use cases for it?

Nothing obvious at the moment, but something might occur to me later.  
Intuitively it seems like it would be useful to have the breaking  
based on content (like something that you knew would be too wide for a  
single cell, but you couldn't predict what column it would start in).  
But I can't think of any specifics.

>
>
> -Boris

Received on Wednesday, 17 June 2009 18:02:02 UTC