Re: [CSS21] Overflow and scroll bar behavior

Hi, Mikko.

Ideal sequence of actions (my guess) looks like this:

0) Remove scrollbars.

1) Measure the content using given width and height of the container (with 
respect of scrollbars).

2) If content width is greater than container, add h-scrollbar,
    otherwise remove it.

3) If content height is greater than container, add v-scrollbar
        3.1) If content width become greater than view width and there is no 
v-scrollbar
               then goto 1.
        3.2) If content width become less than view width and there is 
v-scrollbar
                then goto 1.

4) Done. Pray to the Universe as you are extremely lucky this time.

As you may see, 3.1 and 3.2  are the source of infinite loop (oscillation).

Your solution is a sort of heuristic which means will possibly show 
scrollbars when they don't needed or otherwise - will not show them when 
they needed. Especially when content
width/height is close to container width/height +/- scrollbar size. Seems 
like this is what Mozilla
uses.

Andrew Fedoniouk.
http://terrainformatica.com


Original Message from: "Mikko Rantalainen (by way of Bert Bos 
<bert@w3.org>)"
|
|
| [was: [CSS21] Contradiction in the spec with auto-offset fixed-position
|   elements]
|
| Andrew Fedoniouk wrote:
| > As you know straightforward implementation of overflow:auto when size
| > of content is close to the size of viewport is potentially
| > oscillating function. And could not be implemented without use of
| > heuristics limiting the number of oscillations. (Size of viewport is
| > changing when scrollbars appear). If you will move scrollbars out of
| > the viewport calculation become stable two step process.
|
| How about following algorithm:
| 1) Try to fit content without scroll bars
| 2) If 1 fails, add vertical scroll bar and try again
| 3) If 2 fails, remove vertical scroll bar, add horizontal
|    scroll bar and try again
| 4) If 3 fails, add both vertical and horizontal scroll bars
|    and render the content.
|
| This algorithm is incremental and UA might skip step 3. This algorithm
| never oscillates between two states during rendering because UA should
| return to step 1 only if content changes or UA window has been resized.
|
| > And no one UA handles this 'properly'  as there are no solution at
| > all in the given model.
| >
| > E.g. here is the document
| > http://www.terrainformatica.com/w3/overflow.htm and here is a
| > screenshot in FireFox
| > http://www.terrainformatica.com/w3/overflow-ff.gif As you may see
| > scrollbars are gone but they should be there. "Heuristics" in effect.
|
| The problem isn't "heuristics" but the fact that Firefox has about 100
| pixel minimum height for the viewport, regardless if that high viewport
| can fit the window. If you slowly increase the height of the window,
| you see that vertical scroll bar doesn't change and horizontal scroll
| bar slowly becomes visible again. That is, horizontal scroll bar is
| there as it should. Unfortunately it cannot always fit the visible
| window area. That's a bug but it isn't because the scroll bar behavior
| would be somehow "undecideable" or something.
|
| > IE handles this particular situation better but it has problems with
| >  overflow:auto in different places.
|
| IE always displays vertical scroll bar so it doesn't have similar
| problems with content width.
|
| --
| Mikko
|

Received on Tuesday, 16 November 2004 20:32:15 UTC