RE: scroll bar size in width calculations

I think you're thinking of the containing block as being the size of the scrollable area.

When formatting starts (in case #3) the containing block (the DIV) has initial size of (100 x 100). Then we add content (the P) which is larger than 100px height (see the overflow outside of the light green into the yellow), hence there must a scrollable mechanism to allow viewing of all content. Now however the containing block as changed size to (100 - SB x 100 - SB) which you can't really see since the content inside has fixed size. In this case the vertical scroll by the way causes the horizontal scroll to appear as well.

-Rossen
________________________________________
From: Andrew Fedoniouk [news@terrainformatica.com]
Sent: Saturday, January 05, 2008 12:33 PM
To: Rossen Atanassov
Cc: fantasai; Alex Mogilevsky; www-style@w3.org; Sam Fortiner; Harel Williams; Scott Dickens; Boris Zbarsky
Subject: Re: scroll bar size in width calculations

Rossen Atanassov wrote:
>> Case #3 raises the question: what exactly is content box of an element?
>
> The specified width/height box minus any scroll bar sizes.
>
>> Case #3 shall not show any scrollbars.
>
> If you open case#3 and if you use overflow:auto on the in your example bellow you will not see scroll bars. Here's a modified version that shows that behavior. However, if you specify overflow:scroll and force the scrollbars, then the size of your containing block will change in order to account for the size of the bars. If you look at our cases 5,6,7,8 using floats and percentage sizes you will see how the size of the containing block is changing.
>
>    <!-- there will be no overflow nor scroll bars here since the content fits in the containing block (currently size 100x100) -->
>    <p style="width: 100px; height:100px; background: lightgreen; overflow:auto;">
>      <span style="background:orange">some content that does not fit into a container so it will overflow</span>
>    </p>
>
>   <!-- there will be no overflow, but scroll bars will be present since they are requested by the user. Also the size of the
>   containing block is now taking into account the scroll bars and the width is recalculated (currently size 100 - [size of scroll bar] x100) -->
>    <p style="width: 100px; height:100px; background: orange; overflow:scroll;">
>     <span style="background:lightgreen">some content that does not fit into a container so it will overflow</span>
>    </p>
>

I suspect that you did not get my message right.

I am discussing case #3 from here:

http://www.terrainformatica.com/w3/scroll2.htm

(taken from Alex Mogilevsky message)

This case shall not show any scrollbars as
content (100x100px) fits inside the container
(also 100x100px)

If it shows scrollbars then for the paragraph

<p style="width: 100px; height:100px; background: lightgreen;">some
content that does not fit into a container without getting big enough to
trigger scroll bars</p>

1) outer box [1] does not match margin box of the element.
2) or some box other than border/margin box is used for computation
of content dimensions of scrollable element. Which one?

>
>> If it shows scrollbars then rendering of this case:
>>
>> <!doctype>
>> <html>
>>   <head>
>>     <style>
>>       p { font: 14pt sans-serif; border:1px solid; }
>>     </style>
>>   </head>
>> <body>
>>   <p style="width: 100px; height:100px; background: lightgreen;">some
>> content that does not fit into a container so it will overflow</p>
>>   <p style="width: 100px; height:100px; background: orange;">some
>> content that does not fit into a container so it will overflow</p>
>> </body>
>> </html>
>>
>> must not have text of the paragraphs rendered on top of each other -
>> paragraphs here should have computed height equal to the height of
>> content, like here:
>>
>> <table>
>>   <tr>
>>     <td style="width: 100px; height:100px; background:
>> lightgreen;">some content that does not fit into a container so it will
>> overflow</td>
>>   </tr><tr>
>>     <td style="width: 100px; height:100px; background: orange;">some
>> content that does not fit into a container so it will overflow</td>
>>   </tr>
>> </table>
>
> Table cells will always ignore specified width/height values if the content can't be fit. Consider this scenario

Yes, but not that simple.

For cells overflow:visible is interpreted as overflow:never (or some
other value) by default. True for all UA I can test.

>
> <table>
>    <tr>
>      <td style="width: 100px; height:100px; background:lightgreen;">
>    some content that does not fit into a container so it will
>     overflow some content that does not fit into a container so it will
>    overflow</td>
>    </tr>
> </table>

Compare this sample:
http://www.terrainformatica.com/w3/overflow-visible.htm
in IE and in FF for example.

Two paragraphs on top have text overlapped in FF.
That is because Gecko uses overflow:visible; literally and
it appears as Trident interprets overflow:visible; as
overflow:never for all elements (as for cells). At least I
cannot manage to convince IE(6) to overflow in such cases.

I personally think that IE (Trident) behavior is more humanistic in this
case - leads to more stable and readable renderings.

For IE scrollbar in case #3 (above) is logical (you see no yellow
background there). But it is a mystery for me why Gecko show scrollbars
and yellow space - space that was not allocated to any element.
For the record: Opera (9.x) shows only v-scrollbar there.

>
>
>> This sample, btw, demonstrates another issue:
>> It appears as cells in table use overflow:never value (that does not
>> exist in CSS at all).
>> This and layout algorithm that use flexes (a.k.a. shrink-to-fit) makes
>> tables "unbeatable-by-css" so far.
>>

--
Andrew Fedoniouk.

http://terrainformatica.com

[1] http://www.w3.org/TR/CSS21/box.html

Received on Saturday, 5 January 2008 20:57:12 UTC