- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Mon, 07 Jan 2008 23:39:17 -0800
- 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. Regards. -- Andrew Fedoniouk. http://terrainformatica.com [1] http://en.wikipedia.org/wiki/Nyquist_stability_criterion
Received on Tuesday, 8 January 2008 07:39:20 UTC