Re: scroll bar size in width calculations

Rossen Atanassov wrote:
> The default value of overflow:visible simple allows content to flow
> outside of the containing block (this is what you are seeing in the
> case of the P element inside of the DIV). However, this overflowing
> content does not affect the formatting flow of any other elements
> around the containing block. This is why in your test case bellow the
> overflowing content does not "push down" the next block and table.

Let me break this loop by something more formal:

Pseudocode of height computation, for cells (algorithm A):

   if (cell.style.overflow == visible)
   {
     computed_height = max( cell.style.height, content_height )
   }
   else // cell.style.overflow != visible
   {
     if(cell.style.height.defined())
       computed_height = cell.style.height;
     else
       computed_height = content_height;
   }

other block elements (algorithm B):

   if(cell.style.height.defined())
     computed_height = cell.style.height;
   else
     computed_height = content_height;

IE (at least v.6 I have here) uses algorithm A for computation
of *all* elements - not only cells.

FF appears as using algorithm A for cells and algorithm B for
all other elements in normal block flow.

And yet, take a look here:

http://www.terrainformatica.com/w3/overflow-visible-table.htm

BTW: switch of display from 'block' to 'table-cell' changes algorithm
of computed_height computation too. (Is this defined anywhere, btw?
Chapter [1] is silent about this)

[1] http://www.w3.org/TR/CSS21/visudet.html#normal-block


> 
> In the case of overflow:auto (this is the DIV in test case #3) scroll
> bars are added as needed, i.e. when some element has visible content
> that extends outside of the containing block (again this is the DIV
> in our test case).

This is what I would like to know:
What is a) the name of the box that outline content of element,
b) how it is calculated and c) how it is different from:

[Height computation of] Block-level non-replaced elements in normal flow 
when 'overflow' computes to 'visible':
"If it only has inline-level children, the height is the distance 
between the top of the topmost line box and the bottom of the bottommost 
line box." [1]

I believe that spec is missing definition of computed height value
when 'height' is computed to not 'auto' and 'overflow' computes to 
'visible'. This may be the reason why different UAs end up with 
different values.

> 
> So, to your question : "If so then there must be a mechanism that
> allows to see text of all elements here in full(!)"
> 
> Not really, since in your case they all specify (by default)
> overflow:visible (see above comment).

As it has been shown above such mechanism *is already* there.
It is enough to specify display:table-cell to switch Gecko (and 
Kestrel(Opera) and probably WebKit) layout engine to Trident mode:

   computed_width = max( cell.style.width, content_width )
   computed_height = max( cell.style.height, content_height )

This is esoteric knowledge - it is not specified anywhere.

If IE8 team has changed this already (for e.g. ACID2 passing) then
it will break many existing sites. That is my guess, educated but
still a guess.

-- 
Andrew Fedoniouk.

http://terrainformatica.com


> 
> -Rossen ________________________________________ From: Andrew
> Fedoniouk [news@terrainformatica.com] Sent: Saturday, January 05,
> 2008 1:42 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:
>> 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.
>> 
> 
> Just in case: default value of overflow is 'visible' [1]
> 
> "hence there must a scrollable mechanism to allow viewing of all
> content"
> 
> If so then there must be a mechanism that allows to see text of all
> elements here in full(!): 
> http://www.terrainformatica.com/w3/overflow-visible.htm
> 
> In other words: what is a definition of "all content" for scrollable 
> elements?
> 
> -- Andrew Fedoniouk. http://terrainformatica.com
> 
> [1] http://www.w3.org/TR/CSS21/visufx.html#overflow
> 
> 
> 
>> -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.
>>>> 
> 
>

Received on Saturday, 5 January 2008 23:51:28 UTC