W3C home > Mailing lists > Public > www-style@w3.org > January 2008

Re: scroll bar size in width calculations

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Mon, 07 Jan 2008 23:39:17 -0800
Message-ID: <478328A5.7090102@terrainformatica.com>
To: Brad Kemper <brkemper@comcast.net>
CC: robert@ocallahan.org, Rossen Atanassov <ratan@windows.microsoft.com>, fantasai <fantasai.lists@inkedblade.net>, Alex Mogilevsky <alexmog@exchange.microsoft.com>, CSS Style <www-style@w3.org>, Sam Fortiner <samfort@microsoft.com>, Harel Williams <harelw@microsoft.com>, Scott Dickens <sdickens@exchange.microsoft.com>, Boris Zbarsky <bzbarsky@mit.edu>

Brad Kemper wrote:
> On Jan 7, 2008, at 4:13 PM, Robert O'Callahan wrote:
>> On Jan 6, 2008 3:46 PM, Brad Kemper <brkemper@comcast.net 
>> <mailto:brkemper@comcast.net>> wrote:
>>     Well, I know there are edge cases where one scrollbar causes a
>>     reflow that could also make the other one needed. And I know that
>>     content height will never be 100% predictable, even when specified
>>     in ems, due to various glyph sizes. Does that summarize what you
>>     just wrote? I don't have a problem with that. But there are one or
>>     two browsers (I think IE6 and IE7, and maybe FireFox 2 also, but I
>>     don't have the right computer to check these right now), where the
>>     horizontal scrollbar appears even when there is clearly no need
>>     for it, when overflow is set to auto and overflow-x is not set to
>>     hidden. There is no thumb button, mind you, just an empty,
>>     unusable bar. Safari never had this same problem.
>> We had bugs in this area and probably still do --- it's tricky to get 
>> right --- but we (FF) work pretty hard to minimize the number of 
>> scrollbars we display. Specifically, *I* work pretty hard to ensure 
>> that :-). http://bugzilla.mozilla.org if you have problems 
>> reproducible in FF3 betas...
> Rob, I didn't mean it as a criticism, if it is a bug, as I know it can 
> get complex. I think in IE6, at least, it just goes ahead and draw two 
> scrollbars whenever it needs even one, which is what I feel is incorrect 
> behavior by design. I don't recall  if it was changed in IE7, but I 
> don't think so. 
> I have FF3 at home and FF2 at work. At home with FF3, this problem is 
> not there on a simple test case. I will have to try to get more specific 
> info, and will file a bug report if there still is one.

Mathematically speaking that scrollbar problem has no ambiguous solution 
at all.

Height of HTML document by its nature is a function from its width.
   height = F( width )
When this height exceeds height of the view then v-scrollbar appears
that is effectively changes 'width' in the equation above so you have 
second dependency:
   width = B( height )

System of these two equitations is a classical "positive feedback" 
condition. Solution of such a system may "hunt" or oscillate at some
input values (e.g. when intrinsic dimensions of the content is close to
the size of the view). More on this: Nyquist criterion [1] and around.

That is why all UAs demonstrate different behavior on this.
In such circumstances each team is using their own heuristics.

Defining overflow-y:scroll effectively removes second equitation from
the system (breaks positive feedback) so you are always getting stable 
and unambiguous solutions/results.


Andrew Fedoniouk.

[1] http://en.wikipedia.org/wiki/Nyquist_stability_criterion
Received on Tuesday, 8 January 2008 07:39:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:33 UTC