Re: [css3] [css21] browser specific CSS

On 4/20/2011 8:37 AM, Boris Zbarsky wrote:
> On 4/20/11 5:51 AM, Glenn Linderman wrote:
>> The scrollbars are positioned in the padding area, but the size of the
>> padding is not reduced, rather the size of the content area is reduced.
>
> Ah, more precisely the size of the containing block is reduced, yeah.  
> OK.
>
>>> You have that backwards.  If the containing block assumes that it
>>> needs a scrollbar and lays out at a width that is actually wider than
>>> the table's intrinsic width and the table has a width that depends on
>>> its parent then this can cause the table's height to get _smaller_
>>> (because it's being laid out wider).  And at that smaller height it
>>> does not need a scrollbar.  So you relayout assuming you don't need a
>>> scrollbar, but at that smaller width you get a bigger height which
>>> does need a scrollbar.
>>
>> I might have it backward, but this explanation sounds backward to me...
>> when you relayout assuming you don't need a scrollbar, you have more
>> width, not a smaller width.
>
> If your width is _fixed_ this is true, per our discussion above.  If 
> your width is not fixed, then "relayout assuming you need a scrollbar" 
> means "relayout at width == intrinsic + scrollbar" whereas "relayout 
> assuming you don't need a scrollbar" means "relayout at width == 
> intrinsic".  As long as your scrollbar width is positive, the latter 
> is a smaller width.

Yes, that would be a smaller container width... but the data would have 
the same space, so the layout should happen identically in both cases, 
resulting in no change to the height, and no need to reinstantiate a 
scrollbar.

>
>> Maybe there are too many cases floating
>> around.  Can we handle the case where the table is constrained by its
>> parent separately from the case where it is not?
>
> Not easily, no. 

I just meant as a way of thinking about it, not a coding technique.

> Consider the case when there are multiple tables in the float, some 
> constrained by it and some not.  (Assuming I understand what you mean 
> by "constrained", which I think is actually an incorrect assumption 
> here.  I assume it to mean the table width depends on the width of the 
> ancestor in a way other than via it establishing a containing block 
> that affects shrink-wrapping.)

Admittedly, I was only thinking about one table in the float, but I 
don't think that matters.

Just now I thought of a cell containing a replaced element with a width 
of 100% and an aspect ratio less than 1... it would grow vertically when 
a wider width is provided.  So now I understand the possibility of 
height growing when width grows.  So no doubt this is the sort of thing 
that caused some page displays to be unstable, in early days.

What solution is used when this case arises?  The "obvious easy" 
solution would be to leave room for the scrollbars, but don't display 
them if they aren't actually needed... but that requires a first pass to 
figure out you don't need a scrollbar, a second pass to figure out that 
oops you do need a scrollbar when you try not to have one, and reverting 
to the first pass results plus a blank spot where the scrollbar would 
have been.