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

Re: scroll bar size in width calculations

From: Brad Kemper <brkemper@comcast.net>
Date: Sat, 5 Jan 2008 18:46:30 -0800
Message-Id: <AB57EF65-578A-4EC0-983E-83C1E9F0B3A6@comcast.net>
Cc: Andrew Fedoniouk <news@terrainformatica.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>
To: Rossen Atanassov <ratan@windows.microsoft.com>
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.

If you all say that this isn't actually true, then it may be from a  
more complicated layout that I remember it from, such as overflows  
inside of other overflows, and I will have to do more research to see  
where I encountered this. But I thought it was just doing it on  
normal overflows.

On Jan 5, 2008, at 6:19 PM, Rossen Atanassov wrote:

> You're right in saying that vertical and horizontal scroll bars  
> (especially with orverflow:auto) should only be displayed when  
> needed i.e. non-breakable content requires it. However I don't  
> agree this must be a requirement because it will be hard to measure  
> 'correctness' and/or 'compliance'.
> Consider scenarios when vertical scrollbar is required due to  
> vertical overflow of the content (just like your example of using  
> your email client bellow). Now the content area is reduced by the  
> size of the vertical scroll, hence your content is reformatted. At  
> the same time let's say there is a non-breakable content that  
> requires the horizontal scroll to be flipped on. Well, now the  
> horizontal scroll takes size out of your content height so there is  
> a new reformatting required again... You see where I'm going with  
> this.. I suppose that might be the reason you're seeing the  
> horizontal scrolls.
> So, from the example above, let's say that every different browser  
> has different size of the non-breakable content (very often the  
> case with text due to different glyph sizes). Then, the different  
> behavior will suggest non-compliance...
> -Rossen
> From: Brad Kemper [brkemper@comcast.net]
> Sent: Saturday, January 05, 2008 3:44 PM
> To: Rossen Atanassov
> Cc: Andrew Fedoniouk; fantasai; Alex Mogilevsky; CSS Style; Sam  
> Fortiner; Harel Williams; Scott Dickens; Boris Zbarsky
> Subject: Re: scroll bar size in width calculations
> On Jan 5, 2008, at 12:55 PM, Rossen Atanassov wrote:
>> 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.
> In some browsers the horizontal scroll bar appears whenever the  
> vertical one does, but this seems wrong to me. With overflow:auto,  
> there is supposed to be "a scrolling mechanism to be provided for  
> overflowing boxes"[1]. If the block is not overflowing  
> horizontally, why is there a horizontal scrollbar in some browsers?  
> I know the scrolling mechanism itself is UA dependant (Safari for  
> iPhone has scrollbars that only appear translucently when actually  
> scrolling, and they do not affect width and height of the content  
> at all), but I wish we could change that line to the following:
> auto
> The behavior of the 'auto' value is user agent-dependent, but  
> should cause a horizontal scrolling mechanism to be provided for  
> horizontally overflowing boxes, and  should cause a vertical  
> scrolling mechanism to be provided for vertical overflowing boxes.
> I usually resort to "overflow-x: hidden;" so that I can get  
> consistent results, predictable content heights, and no useless UI  
> elements taking up space when they are not needed.
> As I right this e-mail using mail.app in Mac OS X, there are no  
> vertical scrollbars unless I make the editing window short enough  
> to need them, and would only have horizontal scrollbars if I had  
> unbreakable content (such as an image) that was wider than the  
> editing window. It is similar in concept to overflow:auto.
> [1] http://www.w3.org/TR/CSS21/visufx.html#overflow
Received on Sunday, 6 January 2008 02:46:45 UTC

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