Closed Bug 72540 Opened 24 years ago Closed 21 years ago

Web pages should have a persistent scrollbar for all pages

Categories

(Core :: Layout, defect, P4)

defect

Tracking

()

VERIFIED WONTFIX

People

(Reporter: ian, Assigned: hewitt)

References

()

Details

(Whiteboard: Take discussion to the forum topic 569350 at the above URL)

Attachments

(4 files)

We could eliminate at least one reflow per page load on big pages if we always showed the vertical scroll bar (like Windows IE). There was some talk about this recently. This might therefore be a dup.
Keywords: perf
Never mind. Thorough profiling and jrgm's tests show that this is not a problem.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
Sorry to reopen this. But it's not a matter of performance but a matter of aesthetics. Imagine a website with short and long pages, all pages having a unified layout, with one box centered on the page. On the short pages, since there's more horizontal space, the centered box will slightly shift right.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Reassigning to the skins team. It's trivial for me to fix this on my end, but I need disabled scrollbars supported in all skins first. hewitt, when full support for disabled scrollbars is in, you can reassign this back to me.
Assignee: hyatt → hewitt
Status: REOPENED → NEW
Depends on: 76197
hyatt told me he didn't need this after all
Status: NEW → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → INVALID
This was reopened because of a request that all pages have scrollbars for aesthetic reasons. Resolving it as invalid because hyatt doesn't need it doesn't make sense.
sorry, I didn't read all the comments.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Now that bug 76495 is fixed, I'm not seeing many unsightly reflows from the scrollbar appearing while a page is loading. I have a fast connection, though. Fwiw, here's a page that looks better without permanent vertical scrollbars: <body style="margin: 0px"> <style> iframe{ border: none; width: 100%; height: 100%; margin: 0px; }</style> <iframe src="http://www.mozilla.org"></iframe>
I think this should be implemented only for the top-level BODY, as that is the case for which reflows are most of a problem. FRAMEs and IFRAMEs (as in Jesse's example) are often designed to fit (at typical window and font sizes) in the space available, so the unattractiveness would be worse than the visual instability in those cases. (In some cases, insisting that a narrow navigation frame have a vertical scrollbar would result in it scrolling horizontally, when otherwise it wouldn't have.)
OS: Windows 2000 → All
Hardware: PC → All
The Mozilla "bouncing scrollbars" feature creates an insolvable problem in some existing e-commerce site designs. The problem worked around because of the combination of 2 "features": 1) the width of a page cannot be calculated by any means (even the browser does not know it until the page is fully loaded) 2) FRAME: "scrolling = yes not implemented: forced scrollbars don't show up" The "bouncing scrollbars" breaks frames designs that are as basic as having 2 rows with proportionally aligned content. Proportional alignment is a necessity wherever a window is resizable or the screen size is not fixed, both of which are fundamental boundary conditions on the web. As commercial e-commerce site providers, we are extremely disappointed that some misguided Mozilla designers are prepared to break compatibility with all other browsers in the market (Priority: nothing, Target Milestione: nothing). We are also disappointed that such a basic arithmetic failure can get beyond the design stage. We recognise and appreciate the efforts of the Mozilla team in the area of DOM and CSS standards compliance. However, for us, these CSS and DOM related improvements are overshadowed by more basic issues such as this.
> As commercial e-commerce site providers, we are extremely disappointed that some > misguided Mozilla designers are prepared to break compatibility with all other > browsers in the market (Priority: nothing, Target Milestione: nothing). All other browsers? You mean IE for Windows? Netscape 4 for Windows, Opera 5 for Linux, and Konqueror all behave the same as we do. So far that's 1 for 4, not all (among the browsers I have access to right now). Why is it so hard for "e-commerce" sites to deal with this? Can't you just say that certain things have width of 50% or whatever and let the browser deal with it? Pages bounce around while loading for many other reasons (partial content, image loads if no height/width are specified, etc.).
David, I am sorry this is primary school arithmetics that you fail to grasp. In all other browsers, the usable width of the page is always the inner width of the frame minus the witdth of the scrollbar, whether it is shown or not. If, as it is the case with Mozilla ONLY, the usable width is variable, either 1) full width OR 2) width minus scrollbar width, then you get the "bouncing scrollbars" feature. If I follow what you describe "Can't you just say that certain things have width of 50% or whatever and let the browser deal with it?", then 50% or whatever other proportianl value is ambiguous in that it has TWO possible physical results for width depending on the existence of a vertical scrollbar. And because the existence of the vertical scrollbar even changes dynamically during the rendering of the page, one cannot simply let the browser deal with it because how the browser deals with it cannot be synchronised across frames. There is no interface such as a callback that can be used to re-render an adjacent frame depending on the changed width of another. And quite honestly, I wouldn't want to open this can of worms while Mozilla cannot even deal with the normal things in life - which closes the loop to what I want to say: Keep it simple!
So what you're saying is that *when* Mozilla doesn't create a scrollbar, it does page width calculations as if the scrollbar were not going to take up space, whereas in other browsers that don't display a scrollbar all the time, they leave space for the scrollbar. That's different from what you said the first time, and I just checked that it is true for Netscape 4.x and Opera 5.x, but not for Konqueror. Finally, if you're going to be insulting, you're not welcome here. So either be civil or go away. Thanks.
David, your second statement is correct. There must be a way to know the width of the page in advance. In other words it is not GENERALLY acceptable that the page width is unpredictable e.g. that it depends on the length of the page. If such mechanism does exist as in Mozilla, then there should be a way to disable it (SCROLLBARS=NO). Otherwise web designers have to write their own layout managers that use scripts to generate pages with pixel values instead of percent values which introduces a new level of complexity into some frame based web designs, something that is not very welcome in the web designer community.
Severity: normal → minor
Status: REOPENED → ASSIGNED
Priority: -- → P4
Target Milestone: --- → Future
bht: Could we have an example of such a page?
Ian, I would like to privide this but unfortunately I am not allowed to. But I'll try to demonstrate the concept. The real world consequences are simple: Table columns in a scrollable data frame get out of alignment with descriptive columns in a header frame, depending on the length of the data. The dilemma is that the width of a page depends on its length. Both the actual width and length are not available for any computations, inevitably leading to problems that cannot be solved. A possible, but ugly workaround is to generate dummy lines in such a way that scrollbars are always present, and an "end of page" literal such as users don't get too confused trying to explore the dummy portion of the page.
I'd love to see this marked invalid. As a web developer myself, I hate seeing the space where the scrollbar would be if needed. It makes my pages look unprofessional when there is a large white space down the side of the page. How can your pages possibly scale to different resolutions if you can't handle the 10 pixel difference of having a scroll bar or not? Finally, the majority of other window's apps both hide the scrollbar, and make that space usable when they are hidden.
kerz, I think we have to face the fact that the solution is not that simple. Mozilla's current behavior breaks designs that work well with other browsers, and the rather ugly dynamic "bouncing scrollbars" effect is not necessarily present in other window applications. The issue is that a browser is a more complex application that cannot be compared with conventional windows applications that can afford to use off-screen rendering to a wider extent and just hide the content before it is fully rendered! In contrast, dynamic requirements such as displaying a page that has not been fully loaded over the network, require more sophisticated approaches. IMHO, the current dilemma has been created by pushing the browser performance to new heights without providing the means to control the complexity that comes with this. At a minimum, an option should be provided for web authors to control scrollbar behavior. A "scrolling" attribute in the body tag would be a logical choice (already present in the frame tag). BTW this is broken in frames, please refer to bug 44306 "scrolling = yes not implemented: forced scrollbars don't show up." Also please refer to bug 48634 "Vertical scrollbar breaks window.innerWidth" and bug 76197 "Need a way to display disabled vertical scrollbar" Sorry about this. But while this reflow stunt may be an impressive engineering achievement, the benefits definitely aren't there if the behavior is uncontrollable. At present (things being as they are), this just another can of worms.
I agree with Kerz. I don't like IE's permanent vertical scrollbar, because it makes forces me to focus on the right side of the screen in order to tell if the page can be scrolled. Netscape 4's and Opera's permanant scrollbar-space looks ugly on pages with wide block elements that have borders. Incremental reflow is a convenience for users, not for web developers.
As the original reporter of this bug I should point out that I no longer have an opinion either way. This could be WONTFIXed without me reopening it.
Whiteboard: WONTFIX?
*** Bug 12234 has been marked as a duplicate of this bug. ***
*** Bug 94419 has been marked as a duplicate of this bug. ***
Blocks: 71668
I really hope this turns out as a WONTFIX. It doesn't seem like a "fix" at all to me, and NC4* does not behave that way. Needless clutter just "uglyfies" a webpage and scrollbars steal desktop real-estate. When there is no use for them, they should not appear. This is also how it works throughout the app.
Suggest remove 'perf' keyword as this no longer seems to be the issue at stake in this bug. Also suggest remove the block on 71688 (page loading meta bug). Personally really can't see why all mozilla users should have to lose screen estate so that frameset-loving web designers have an easier life. And bug 44306 seems to cover their problems. Moreover, supporting a "scrolling" attribute on 'body' isn't the right thing to do unless it's part of the W3C spec for the body element.
I'm the person to blame for suggesting this idea to Hixie in the first place, and I did so for the sake of users rather than Web designers. The idea being that on a fast computer with a slow connection (== high incrementality), the constant disappearance and reappearance of the vertical scrollbar between pages would be annoying. However, no other Mac browser that I know of has a permanent scrollbar, and I don't mind the disappearance and reappearance of the scrollbar too much, so it doesn't seem to be that important. What might be important, though, is that without a permanent vertical scrollbar *or* space left available for it, the width of the canvas can (in some cases) depend on the height of the canvas *and* vice versa simultaneously. If the canvas is long enough, the viewport gets a vertical scrollbar, which makes the canvas narrower, which causes a reflow where the canvas gets even longer. This might only be as harmless as causing the occasional document to have both horizontal and vertical scrollbars when neither were actually necessary (a similar problem was present in the Program Manager in Windows 3.x). Or, in a freak case, I *think* it could cause an infinite loop where a script was repeatedly adding/subtracting content in order to deal with a viewport which alternately did and did not have a scrollbar. (I don't think this is that far-fetched; it's only a small step from <http://www.msn.com/>, which -- if you're using MSIE for Windows -- shows or hides a yellow box of features depending on the width of the browser window.)
I agree. the height/width dependency is a fundamental dilemma. It is a new source of instability. I must admit that I cannot propose a solution for this other than a new scrollbars body tag that would control scrollbar behavior.
Well I don't like permanent scrollbars. So one proposal is... another pref [Fortunately the one frame of mine where it matters already has scrollbars=no] ...another option is some (Gecko-specific?) CSS e.g. body > :-moz-vertical-scrollbar { visibility: collapse; } body:-moz-vertical-overflow > :-moz-vertical-scrollbar { visibility: normal; } This way it's the page designer's fault if the page is unstable :-)
bht: i don't understand your problem to be honest. How could the scrollbar behaviour restrict your site design? You say: > If I follow what you describe "Can't you just say that certain things have > width of 50% or whatever and let the browser deal with it?", then 50% or > whatever other proportianl value is ambiguous in that it has TWO possible > physical results for width depending on the existence of a vertical scrollbar. i'd say that there are a whole lot more then 2 different possible physical results, when the user resizes the browserwindow the physical size avalible for content goes through a wide array of values. That is why HTML (well, CSS really) layout is flowing, instead of positioned like pdf. Could you please explain in more detail how the scrollbar causes problem for you, a small example would be great. mpt: there is no risk that the browser goes into an eternal loop of adding/removing scrollbars, there is special code to prevent that. But yes, it is possible that we end up with showing both scrollbars when neither is needed. However this is *very* uncommon, and can only happen when the user resizes the window. I'm sure that it would be possible to write a script that would end up in a loop of adding and removing something to the page while a scrollbar is added and removed. However this is just as possible with the horizontal scrollbar (which all browser dynamically add) as it is with the vertical scrollbar, and has to my knowledge never happened, so I wouldn't worry too much about that. Also, there is a gazillion way to create a fubar'ed script, there's just no way stopping people doing it :-) So all in all, unless someone comes up with a (resonable) design that is impossible to create due to the maybe-existence of the scrollbar i would say that this should be WONTFIXed
Jonas, the application requirement is to get a predictable canvas width. In particular, a fixed scrollbar width must be reserved. If not, then the following occurs in case where frame 2 has no scrollbar: ......................................V--Must be reserved for scrollbar | | | | Line No | Item ID | Description | | <- Frame 1 =========+=========+==================== fixed 1 | CAT-1 | Foobar_1 | | ---------+-----------+-----------------| | <- Frame 2 2 | CAT-2 | Foobar_2 | | scrollable ---------+-----------+-----------------| | no scrollbar Col 1 10% Col2 10% Col3 Remainder Both frames have tables whose columns must line up. Widths are specified in relative percent values as to be independent from screen resolution and user re-sizing. In reality and in this line art drawing, columns in frame 2 that are coded exactly the same way as in frame 1 get allocated different width depending on scrollbar existence in frame 2. Strictly speaking, frame 1 would have to reflow with added scrollbar space depending on the outcome in frame 2. It's really simple. I would be very disappointed if the Mozilla team capitulated here. WONTFIX is not a solution. So far I haven't seen a cross-browser compatible solution for scrollable lists with aligned fixed headers that would not be broken by this. I think IE has special table tags for this but with frames one can do this for every browser (It even works with IE3, Netscape 3, HotJava etc.).
> I would be very disappointed if the Mozilla team /capitulated/ here. please don't use that word. imo your usage is wrong and any 'fix' would be a capitulation. if you're using css, i'd imagine you could use iframe(s) instead of a frameset and you wouldn't have the hypothetical problem you're describing.
Thanks for the suggestion. But iframes don't work in Netscape 4. Frames do work. So I need another word for /capitulation/. I replace it with "inconsistency", something softer. IMHO the inconsistency is that a new behaviour was introduced that breaks existing designs without providing a workaround option to emulate the original de facto standard behaviour. The lack of support for "scrolling = yes" with reserved space for scrollbars even if not shown is an inconsistency. Increasing screen real estate by not showing scrollbars is a good thing. Breaking the arithmetics to calculate the available screen width is "inconsistent". Not allowing web designers to suppress the bouncing scrollbar effect is also "inconsistent". It is a dilemma that a new, not yet standardised tag would be required to control accurate behaviour. Too bad IMHO. Mozilla needs it.
Blocks: 48634
Disagree with this bug also. This is one one of the thing I like with Mozilla, not having the vertical scrollbar if not necessary.
Okay. I started up another bug http://bugzilla.mozilla.org/show_bug.cgi?id=94419 which has since been marked as a duplicate of this one and so I;m making my comment in here with the hope that it will make a difference and put Mozilla up front of all the rest. The way I see it is that the scrollbars vertical or horizontal are not, and in my opinion should not, be part of the HTML layout. They are purely there so as to allow the scrolling of the canvas/frame that they are related to. So If your canvas/frame, not window and by that I mean the space available after taking away any space taken up by other widgets, like say the sidebar but not the window borders, is say 600 pixels wide then the rendering should be working on that and not take into account the vertical scrollbar to the right because this is part of the window controls. This would should avoid the problem with the bouncing and possible looping situations as well. No I have no real programming prowess when it comes to C or C++ and their way of handling widgets and other controls but I would think that the way to do it would be to place the scrollbars above the canvas used for rendering. I imagine this would be possible?
*** Bug 125832 has been marked as a duplicate of this bug. ***
This bug has been dormant for some time but it would be nice to see some resolution. Many people are focusing on the aesthetic blight of having unusable space where the scrollbar would be. But the real issue comes to light when a series of pages is considered. An example: Lets assume a family of pages where the content is centered in a constant-width table. The length of the table depends on the content to be displayed. Some pages have enouh content to force a scrollbar, most do not. There are graphical elements placed at the top and bottom of each table for navigation. When the scroll bar is present, the entire document (which is centered and constant-width) shifts over by half the width of the scroll bar. This means that the navigation elements have now moved, and if the visitor is rapidly clicking through a series of these pages, the mouse cursor may no longer be over the nav graphic (or worse, over a different graphic, such as jump-to-last-page). There is no way to fix this problem in Mozilla, at least no way that I can think of. IE does not have this issue because of the permenant vertical scroll; NS4 and Opera reserve the scroll space, making the table appear slightly off-center but at least its position is fixed. Mozilla causes the table to jitter between pages, and this is unacceptable for me. It is my opinion as a web designer that there should be a CSS rule or BODY tag that reserves vertical-scrollbar space. Whether or not it should be *default* behavior is not my concern.
I second to Henry because resolutions used in modern pcs are so large that the loss of horizontal space isn't a big issue anymore, when compared to performance gains.
Also if the scrollbar-reserved space is _really_ needed then that page can be put in a frame with a scrolling=no attribute and - if required - an additional 0 width frame so users won't notice the frameset setup. In other words even the most extreme requirements can be met if the scrollbar space was reserved as in IE and Netscape 4, while the bouncing scrollbar nuisance would be eliminated. BTW all of the few users I know who use Netscape 6 think it sucks because of this.
I strongly _discourage_ the frames-solution proposed by bht@actrix.gen.nz. This is not a solution, not a work-around, not a hack. It's pure nonsense. While Mozilla is trying to stick to the standards, are we going to promote the use of frames, which is depracated because of thousand reasons I'm not going to repeat here. Please give us either an inactive vertical scrollbar or an area as wide as the vertical scrollbar that doesn't count towards the width of the page, but that takes the background-color and background-image of the page.
Erich.Iseli@iseli.org, would you please provide a reference to an official and widely accepted document i.e. a W3C standards paper that declares frames deprecated. I am always interested in the latest developments such as the one you are referring to.
bht@actrix.gen.nz, http://www.w3.org/TR/xhtml11/doctype.html#s_doctype is the latest version of xhtml, which got rid of all depracated elements from html. There is no mention of frame, frameset and iframe. iframe will be replaced by object, but obviously, the "frames" are history.
How about my suggestion about 8 comments above. Make the scrollbars a part of the interface and not the internal frame/canvas. This would also possibly mean that recalculations because of wrapping caused by the addition of scrollbars would be reduced and therefore a possible performance gain. Again let me reiterate that I have no knowledge of this level of programming in C/C++ yet. Although at this rate I might be tempted to give it a try just to submit a possible patch.
Isn't there a CSS overflow: value that can be used to force scrollbars to appear in a particular direction regardless of their necessity? Wouldn't body {overflow: something} in the rare case that a page author really needs a predictable scrollbar-presence be sufficient?
Yes, you can use CSS to make the vertical scrollbar always visible. Always show both scrollbars: data:text/html,<style> html { overflow: scroll; height: 100% } </style> foo<p>foo<p>foo<p>foo<p>foo<p>foo<p>foo Always show a vertical scrollbar and never show a horizontal scrollbar: data:text/html,<style> html { overflow: -moz-scrollbars-vertical; height: 100% } </style> foo<p>foo<p>foo<p>foo<p>foo<p>foo<p>foo Conversely, you can make IE's vertical scrollbar auto (instead of always shown) using <style> body,html { overflow-y: auto } </style>. When you set IE's scrollbar to auto, it works like Mozilla's, only taking up space when it's there. Guess what line I just added a line to my IE user-ie.css :) (I like IE's overflow-y better than Mozilla's -moz-scrollbars-vertical, because IE's allows me to make the horizontal scrollbar auto while making the vertical scrollbar always visible.)
*** Bug 139822 has been marked as a duplicate of this bug. ***
*** Bug 76197 has been marked as a duplicate of this bug. ***
*** Bug 140434 has been marked as a duplicate of this bug. ***
I think we should WONTFIX this. I've been using several sites recently that look stupid in IE because of the disabled scrollbar but look nice in Mozilla.
I think this should be fixed because both IE and NS4.x reserve the space for a scrollbar whether or not it's the actual scrollbar or just the scrollbar area. In both cases the scrollbar area is seperate from the content area, as it should be. The scrollbar is a window control and should not be intermixed in with the content area. They sould be seperate.
My suggestion would be to copy the behavior of NS4. Don't show the scrollbar if it is not needed but don't let any of the page content occupy that space. That way the scrollbar space inherits the page background color so it's not ugly, and the page content doesn't shift around depending on if the scrollbar's present or not. When using NS4 you really don't notice the space if the scrollbar's not there but a person _will_ notice the content of a page shifting between scrollbar and no scrollbar. Especially since mozilla has supirior rendering to where the page doesn't even appear to reload when switching pages, the content just changes instantly. So you notice that page shift.
Here, as I understand it, is the problem... It is desired by a significant number of authors and users to have a situation where * The vertical scrollbar is present, but disabled until scrolling is required. This prevents Unsightly Reflow. * The horizontal scrollbar is completely absent until it is needed. It doesn't cause a reflow for the horizontal scrollbar to pop in, so there's no problem with it doing so. This is the default behavior for IE. However, AFAICT, there's *no way* to get Mozilla to work like this. That should be fixed--with Mozilla extensions to CSS if necessary. The default behavior of "overflow: auto" is less important than having this functionality available *at all*.
As I see it, there are three table-based HTML page layout paradigms that we need to concern ourselves with, regarding vertical scrollbars: 1) the centered table with width less than 100% of the browser window (the width is usually specified absolutely in pixels) 2) the left justified table with a width equal to 100% of the browser window 3) the left justified table with a width equal to 100% of the browser window, containing centered elements (that should not shift between similar pages of varying lengths). For each of the three layout paradigms above, a *different* vertical scrollbar behavior is called for---and after reading the previous posts on this topic, I have a feeling that most web designers may not agree on which vertical scrollbar behavior is optimal for each of the cases above (and all those others that exist). Which generally means, the decision should be left up to the web-designer (and not the web-browser), through the following extension I'd like to propose to CSS: vertical-scrollbar: auto | always-on | always-off | reserved auto - this is mozilla's current behavior, the scrollbar is rendered and the page canvas resized when the page elements are taller than the page canvas. this would probably remain the default behavior, optimal for pages without table-based layout, and for tables with width=100% but without centered elements (like navigation bars/menus) that might shift when the scrollbar is rendered for longer pages. always-on - this is IE's current behavior, the scrollbar is shaded inactive when not needed and is rendered when necessary. This would probably be optimal for page designs that have centered elements within tables that occupy 100% width of the page canvas. always-off - this would supress the rendering of the scrollbar regardless of the height of the page elements reserved - this is the alternative proposed by wjbell@belletc.net (and others) where the "vertical scrollbar zone" is reserved and takes on the color/image of the page background, preventing page designs of the centered table variety from shifting when the scrollbar is rendered. I believe that the overflow attribute is not appropriate for this solving this dilemma.
I agree with Justin Watt that that would be a good solution. That way the page author has the control to stop the shifting on a centered content page. Then again, I wouldn't mind just having a default reserved space that inherits the pages background color. Like someone else said, with todays resolutions and monitors sizes nobody will miss a few pixels on the right hand side of the screen. And with it being the same color as the background, you wont see anything unsightly in your browser window. I have a test page on my site that shows how the page jump turns a uniform looking layout into somthing that looks broken. Click on the test link from the main page then use the back button to switch between. http://www.belletc.net/
The following is an example of a page that I described as layout type (2) in comment 51, where the table has a width of 100%, but no centered elements. I'm guessing that that would probably *not* look good if the "vertical scrollbar zone" was reserved by default and rendered with the background color/image of the rest of the page (white): http://www.sapient.com/ This layout technique I think is being called "fluid web design" in some circles---meaning that the page is designed to expand gracefully to various monitor resolutions and window sizes, using a combination of background images, expanding tables with background images, and foreground elements. In this case the web designer *wants* the page to stretch, panoramically, from one edge of the browser window to the other, without shaded scrollbars or reserved scrollbar space in the way. However, yes, for all page layouts of the centered variety, ex: http://www.unc.edu/ the solution proposed by wjbell@belletc.net is optimal, with the inactive scrollbar solution (IE) being the next promising. Considering all this discussion, one can see why the IE developers chose the easy way out. As far as successfully preventing page shifts in a website environment, it is a smart way to go. A CSS extension as I proposed above is more creative though--gives more power to the people. I sent a modified version of comment 51 to www-style@w3.org, as the W3C's CSS working group is currently drafting CSS3. I imagine there may be someone related to Mozilla or otherwise with closer connections to the W3C who might be able to suggest this extension being included into the standard?
> The following is an example of a page that I described as layout type (2) in > comment 51, where the table has a width of 100%, but no centered elements. I'm > guessing that that would probably *not* look good if the "vertical scrollbar > zone" was reserved by default and rendered with the background color/image of > the rest of the page (white): > http://www.sapient.com/ If you open up this page in NS4 it has the white reserved space, but it doesn't look that bad. But since this type of page is less common, and it's a certain style of page, it might be better to have the default behavior of mozilla to reserve the scrollbar space like NS4 but have the CSS options that Justin Watt mentioned as an option for web developers to turn it off. So maybe somthing like: vertical-scrollbar: reserved (default) | auto | always-on | always-off The scrollbar appearing and taking over content space just seems unclean to me. The scrollbar is part of the window controls and should be seperate from the content screen and neither one should effect the other. JMO
*** Bug 144033 has been marked as a duplicate of this bug. ***
This causes two annoyances for me: 1) Page reflow while during loading of a page. 2) Pages within a site may not look the same. A consistent feel is important to connect to a reader. For pages that are short and intend to use up the space, a css property to make the scrollbar disappear should be sufficient. I admit though that this may be just a personal annoyance and that others may not agree with me. My vote is for this to be fixed rather than wontfixed.
Please make this a preference, if for no other reason to end endless debate. If possible, anything GUI generating hard opposing opinion should be settable preference. Nobody debates colors of hotlinks, almost nobody changes default. With this, it clear different people want different appearance and would value preference setting if it were available. Can you even imagine "I know as a fact that God himself prefers blue hotlinks, not green, so you sinful moron, don't ever again speak this blasphemy about green." Some of what's above isn't far from such sillyness.....
This isn't an end-user preference, it's a web author preference. Letting the user change the bahavior does nothing for the web page author with a centered layout. The best thing to do would be to have a CSS rule that allows authors to reserve the scrollbar area and not let any content occupy that space, like what was proposed in comment #51.
> 1) Page reflow while during loading of a page. Paint suppression takes care of this most of the time. > 2) Pages within a site may not look the same. A consistent feel is > important to connect to a reader. If some pages have a scrollbar-width white gap and some don't, they look different to me. If some pages have a 780px-wide content box and some have a box that's a scrollbar-width smaller, they look the same to me. Do you have an example that looks more consistent when space is reserved for the scrollbar?
> If some pages have a scrollbar-width white gap and some don't, > they look different to me. The idea is that the scrollbar area, if reserved, inherits the background color, or image, of the page. > If some pages have a 780px-wide content box and some have a > box that's a scrollbar-width smaller, they look the same to me. > Do you have an example that looks more consistent when space is > reserved for the scrollbar? Absolutly. I have a test page set up here: http://www.belletc.net/index.cgi?page=test Go there in mozilla and watch the page shift areound. Go there in NS4 and see how the scrollbar area inherits the background color and the page doesn't shift around.
What I meant to say was "If some pages have a scrollbar-width background-color gap and some don't, they look different to me." After looking at your testcase, that's still my opinion. One page has a large gap between "print version" and the edge of the page in Netscape 4, and the other doesn't.
> One page has a large gap between "print version" and the edge of the page in Netscape 4, and the other doesn't. Yeah, but that's not nearly as unsightly as a whole page layout shifting. Besides, if it's a CSS rule that the page author can apply, 1: It will only effect users that visit the pages where authors have specified it. And 2: If it's a CSS rule then a person who never wants that behavior can always put: vertical-scrollbar: auto !important; Or whatever in his/her usercontent.css.
> If some pages have a scrollbar-width white gap and some don't, they look > different to me. If some pages have a 780px-wide content box and some have a > box that's a scrollbar-width smaller, they look the same to me. Jesse: I guess you miss the point I was making. The current Mozilla behavior forces me as an author to use a fixed width. I am doing something I don't believe in because I want my sites to look good in Mozilla. Now if I had the option to reserve 20px for the scrollbar then I would have no reservations about using 100% width, because I know my pages would look consistent in Mozilla.
Here's another use for reserved scrollbar space: menulists. Have you noticed that on long menulists (e.g. preferences/languages/default) the scrollbar appears on the right of the list, instead of within the list? Please could space be reserved for the scrollbar on menulists as well. Of course a separate bug would have to be filed on themes to use the feature.
Correct me if I'm wrong, but the bug description seems misleading based on recent discussion, so altering it.
Summary: Web pages should always have vertical scrollbars → Web pages should have vertical scrollbar space reserved
Is there any backing in the specs for doing this? I think this should be marked WONTFIX (and I originally reported it). I do think we should give authors a way to control this (an @ rule, maybe?) but I think our current behaviour is best.
No longer depends on: 76197
I am inclined to agree with WONTFIX. I think part of the issues raised here could be resolved or at least alleviated by fixing bug 76197, thereby making the "scroll", "-moz-scrollbars-horizontal", and "-moz-scrollbars-vertical" values of "overflow" more usable.
Resolving WONTFIX.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago22 years ago
Resolution: --- → WONTFIX
Hixie, please quell my fear. In marking this bug WONTFIX, you are assuming that bug 76197 *will* be fixed and that fix will *by default* reserve the vertical scrollbar space with a disabled scrollbar? (... and possibly allow the web author to relinquish that space with css.) If not, then I fear that this bug will become a favourite knit-pick for web authors since moz's behaviour will be so different from that of past and present browsers. I agree wholeheartedly with wjbell’s comment 48.
Yes I think Bug 76197 is indeed more basic than this one. I would prefer that that bug be fixed instead.
By saying WONTFIX I am saying that for short pages there should be no scrollbar and no gap for a scrollbar. I do, however, believe CSS should have a way of letting authors control this.
Ian, That statement is good for single pages, but for multi-page web /sites/ it overlooks two facts: 1) Good websites have a template where all pages are made to look the same except for the content. 2) Most sites have a combination of long and short pages in them. Yes, single standalone pages look better without a scrollbar - I do agree with you wholeheartedly here - but if a short page is part of a set of pages with both long and short pages, then it breaks the template. What we want is consistency within a site - all pages from the same site that are based on the same template viewed from the same browser on the same computer should have the same width when rendered.
...which is why sites should be able to control this, like I said.
Should that be a separate bug, then? (Give authors the ability to reserve vertical scrollbar space) Or should this bug handle it? Or should it be the other way around? (Moz reserves the space but authors have the ability to display:none that space) I prefer the second. Short standalone pages are rare, and it's easier to remove a scrollbar that is there than add a scrollbar that isn't there. I suggest -moz-scrollbar {display: none;} to make the scrollbar disappear.
No longer blocks: 48634
This bug is very similar to bug 48634 (probably a dup).
*** Bug 156177 has been marked as a duplicate of this bug. ***
Please see my duplicate bug 156177 for another example of why Mozilla's current behavior looks crappy.
Whiteboard: WONTFIX?
-moz-scrollbars-vertical does not help in my case. When it is applied, the page is only as tall as the smallest nested <DIV> with a scrollbar on the side. This makes the content only 200px tall on my test case with a long scrollbar. This is just silly. When did the scrollbar become part of the Web page, and it it indeed is part of the Web page, why can't the author control it properly?
C'mon guys. Please don't make my centered content jump around.
Undoing damage to summary, and reopening. Since my last comment, I have noticed a number of reasons why this bug should be fixed. In order of importance: (1) The lack of a vertical scrollbar causes centered/righted elements to jump around once the page gets longer/shorter than a screenful. No, paint suppression does not solve this; if it did, I would consider that a bug, as I shouldn't have to wait ages for a page to get longer than a screenful before I get to see any content. And paint suppression can't do anything if the layout is shared across multiple pages. Nor would `reserving space' for the scrollbar solve the problem adequately, since it would make the layout look lopsided for short pages. (2) The omnipresence of the vertical scrollbar would prevent the scrollbuttons in the horizontal scrollbar (where present) from jumping around once the page gets longer/shorter than a screenful. (3) It's breaking the interface guidelines on *every* platform for which I know of the existence of both a Mozilla implementation and interface guidelines for scrollbars. Windows <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch07d.asp>: `The common practice is to display scroll bars if the view requires scrolling under any circumstances. If the window becomes inactive or is resized so that its contents do not require scrolling, you should continue to display the scroll bars.' Mac OS 8/9 <http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-121.html#HEADING121-4>: `If the document is no larger than the window, the scroll bars are inactive. This means that the rectangles are outlined, but there is no gray area, no scroll box, and the arrows are hollow (their outlines appear).' And Mac OS X <http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/AHIGWindows/Scrolling_Windows.html>: `If the entire contents of a document is visible in a window, the scroll bars do not contain scrollers.' (The interface guidelines for GNOME and KDE do not appear to mention scrollbars.) (4) If the Status Bar is turned off, the lack of a vertical scrollbar causes part of the page to be hidden behind the window's grow box. (An alternative solution to this problem would be to make the Status Bar compulsory, but that wouldn't solve any of the other problems.) (5) It's inconsistent with other programs, such as AppleWorks, iTunes, and (most obviously) the Finder, all of which use vertical scrollbars even when the full length of the content fits in the window. *None* of these reasons have anything to do with Web designers, who (for the purposes of this bug) I don't give a stuff about, and it's rather unfortunate that the bug report got invaded by them. The bug appears to have been wontfixed under the assumption that author configurability makes the default user experience irrelevant, and that assumption is (as usual) incorrect.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: Web pages should have vertical scrollbar space reserved → Web pages should always have vertical scrollbars by default
Not only centered/righted elements, but also left-aligned pages that use percentage for their width.
But for me the most important reason for this to be fixed is still the consistency of layout of pages in a web site. Not because the spec say so (though that is a compelling reason) but because it is the logical thing to do. In fact, there is really no compelling reason for Mozilla to behave the way it currently does.
> (1) The lack of a vertical scrollbar causes centered/righted elements to jump > around once the page gets longer/shorter than a screenful. I have only noticed this on one page, and it is a Mozilla demo. Please provide the URI for an actual web page showing this behaviour. Argument 2 is merely an extension of argument 1. > (3) It's breaking the interface guidelines on *every* platform for which I > know of the existence of both a Mozilla implementation and interface > guidelines for scrollbars. There is precedent for this, for example PowerPoint, Windows Explorer. We shouldn't blindly follow specs even when they are stupid. When specs are stupid we should either ignore them (if that doesn't hurt interoperability) or get the specs changed. >(4) If the Status Bar is turned off, the lack of a vertical scrollbar causes > part of the page to be hidden behind the window's grow box. (An > alternative solution to this problem would be to make the Status Bar > compulsory, but that wouldn't solve any of the other problems.) The likelyhood that there is any important content in the bottom left 12x12 pixels is remote. In the remote case of their being anything there to care about, users can reenable the status bar temporarily. There is precedent for this (e.g. Windows Explorer). Argument 5 is merely an extension of argument 3. > *None* of these reasons have anything to do with Web designers, who (for the > purposes of this bug) I don't give a stuff about, Author are important, but not as important as users. I think this bug should be WONTFIXed because *as a user* I don't like seeing a big gray bar to the right of my window when there's no reason for it to be there. (a) The scrollbar is unsightly when the page doesn't require it. (b) The scrollbar being present on the window's viewport but not on an <iframe>'s, <textarea>'s, <object>'s, or <img>'s viewport is internally inconsistent. (This is much worse than being inconsistent with other apps on the system.) (c) Other applications which display content (rather than displaying an editor's view of the content) remove scrollbars when they are not necessary, so that the user is not distracted by pointless UI. (d) It makes no sense to have this behaviour for vertical scrollbars and not horizontal scrollbars (and in fact this would be inconsistent with the UI guidelines you quoted), and having disabled horizontal scrollbars is even worse. (This point of view is even shared by WinIE, which disabled vertical scrollbars but _hides_ horizontal ones.) (e) Pages which are special cases and will be frequently increasing and decreasing their content (such as the demo I mentioned at the top of this comment) should, IMHO, specify the viewport's scrollbar settings themselves, and so should not be considered for this bug.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
QA Contact: petersen → ian
Resolution: --- → WONTFIX
Keywords: perf
>> (1) The lack of a vertical scrollbar causes centered/righted elements to jump >> around once the page gets longer/shorter than a screenful. > I have only noticed this on one page, and it is a Mozilla demo. Please provide > the URI for an actual web page showing this behaviour. Ian, see: http://nchcap.unc.edu/ (click between "home" and any of the other links--the page appears to jump left when the scrollbar is added) >> *None* of these reasons have anything to do with Web designers, who (for the >> purposes of this bug) I don't give a stuff about, > Author are important, but not as important as users. With an article like this on the front of news.com, I'd hope you'd both think authors /and/ users are *tremendously* important: "Sites bow to Microsoft's browser king" http://news.com.com/2100-1023-941926.html?tag=fd_lede I vote first for a permanent vertical scrollbar that is dimmed when not in use. Not an elegant solution, but a solution that does not create any site-continuity problems ("unsightly" as it is). I then hope that we could put our heads together and come up with a more creative solution to prevent a site like http://nchcap.unc.edu from becoming annoying to navigate.
Ran into this "bug" this week actually when we have a navigation that expands using the css display. The navigation is on the right side of the page and it look *really* bad when suddenly the whole page "jumps" because suddenly the scrollbar appears. The site mentioned in comment 84 reloads its content, but still visible. In our solution it looks simply bad because of this. :-( my 2 cents...
A scrollbar is part of the interface just as a back or forward button might be. Having elements of the interface appear and disappear depending on whether they are needed is silly in any other context. Why not have the back and forward buttons in Mozilla disappear when there are no pages in the history? Why not have the stop button appear only when a page is loading, and then disappear when it is done? Why not? Because it would look stupid to have the toolbar icons bouncing around as you browsed, having buttons appear and disappear. This is all facetious of course, but to illustrate a point. No one would think of designing an application with magically disappearing interface elements except when it comes to scrollbars for some reason. Now why is it that an exception is being made for scrollbars?
I agree with Hixie. Btw, if you turn off the status bar in Windows Explorer or Notepad (WinXP), the resize grippy is hidden unless both scrollbars are visible.
> http://nchcap.unc.edu/ > (click between "home" and any of the other links--the page appears to jump left > when the scrollbar is added) Oh come off it. Like users are going to notice that. The home page looks better when it has no scroll bars, anyway. Big deal.
Totally disagree, it is very visible. And as I mentioned, if you have a menu to the right that expands using the css property display, its not only visible but very annoying. Our company is developing a site now where this occur and it does not look good. Will try to make a testcase a soon as I have some extra time to show this.
I agree with comment #86 made by Jerry Baker. The value of his statement is an order of magnitude higher than many others such as misguided by the minute gain of screen real estate achieved by automatic scrollbar bouncing. These gains are interesting but have little practical value if they cannot be controlled. Please imagine the following simple scenario: A dynamically updatable page is first loaded with minimal content not long enough to require scrollbars. The user presses a button on this page to update it (via a http connection to the server). The page updates itself with extended content, the button moves away from underneath the user's mouse cursor and all other thext jumps around plus of course suddenly the scrollbars appear. What a joke, isn't it? Ha, Ha, Ha! I am coming from the direction where the web authors definitely lose control over the screen geometry. But the way I think wrt this issue is very similar to Jerry's. What counts is what can be done for the end user and the fact is that the user does not notice unused reserved space in comparison with the highly irritating effect of uncontrollable dynamically misaligned content. I agree with comments made elsewhere that users should not carry the burden but rather web developers even if it means a lot of work. But if it is IMPOSSIBLE for a web developer to achieve a simple goal such as accuracy in content alignment then the web browser has missed its goal by miles. However whether I aggree or not that doesn't matter in the scale of things in the real world. By that I mean that Mozilla 1 / Netscape 6/7 have currently close to 0% market share. So the question is whether users will tolerate glitches such as this. I think they won't. Mozilla is much easier to wipe from the computer than to install it. In other words every good engineer or mechanic who wants to release a good service or product has to do at least one thing before getting in contact with a highly valued customer audience: He has to get the dirty grease out from underneath his fingernails and adapt to the audience not vice versa. And he shouldn't talk techo gibberish and how the customers should behave. I have just opened http://www.sapient.com/ as suggested by Comment #53 From Justin Watt. Very smart, superior design. The user interface elements (vertical tabs, vertical scrollbar) are close together for most convenient navigation (sorry, left-handers). If Mozilla breaks this design then that's too bad for Mozilla not for that site. I don't know what went wrong with most other sites that force silly mouse acrobatics between the left menu bar and the right scrollbar. The fact is that vertical scrollbars are always right and not left. Simply silly, isn't it? Good for a laugh anyway.
Ian: Re comment 88, of course users will notice it. How do you think it got reported, and then all these people got here in this bug?
Look, I don't mind using some method to workaround this so long as Mozilla has something that is non-proprietary to control it. In an ideal world there would be a way for page authors to turn on, or off, permanent scrollbars (disabled when unneeded ala IE Win), and a way for users to override this behavior if they so choose. I would say that the default should be to behave like every other browser on the planet (at least on the Windows platform).
>I would say that the default should be to behave like every other >browser on the planet (at least on the Windows platform). Okay, I would say that the default should be to behave like every other browser and other application on the planet (at least on the Macintosh platform). Now what? Of course, there is the "fix" mentioned in comment 43, but I suspect it isn't enough for the purposes of those who want the scrollbar space to stay reserved in all cases.
Different behaviors on different platforms just like we do for various other UI conventions. My understanding is that IE and NN4 behaved the same way on Mac as well though.
Re: a potential fix in comment 44: -moz-scrollbars-vertical doesn't work properly right now. See my comment about this in bug 76197
FWIW, I feel strongly that the scrollbar, whether visible or not, is a control. It is not part of the content, but part of the application, and something that designers and viewers should be able to mostly ignore. Adding *features* to allow either to tweak scrollbar preferences would be cool, but does not solve the initial problem as posted, nor does it operate on the principle of least surprise. Having to add CSS to accommodate specific browsers or browser versions for basic behaviour like this is precisely what we need to be getting away from. Being able to define cool CSS classes to tweak scrollbar beahviour should be optional, not required.
Look, this is aweful for both the developer and the end user. Most users expect the document's width to remain constant until the window is resized. Many developers use centered or right-aligned navigational items across multiple pages, and expect them to always fall on the same location. There is no reason for Mozilla to change the width of the canvas. It confuses and frustrates everybody, except for those who complain that short documents look more pleasing without a disabled scroll bar. I can't comprehend how they have won this "feature" at the expense of the rest of us. This bug is the largest of three reasons I cannot recommend Mozilla to coworkers, because our web administration pages have small right-aligned navigation buttons that should not shift position between pages (but do, often lining the cursor up with an unintended button instead).
Comment #97 finally raises a few questions: 1) Why are we as the majority of contributors (= voters who wish to have this bug fixed) behaving like losers ? 2) Why do we (who have analytical skills and not just opinion) continue to waste our time with emotional discussions while the overwhelming array of facts clearly demands that this gets fixed? 3) Why is it only up to the original reporter's opinion whether this gets fixed or not?
Note that the people who would be annoyed if the behavior were what you want aren't angry about it and aren't adding tons of comments to the bug. If we switch the behavior, we'll annoy a different set of people, who could again produce the majority of comments on a bug.
Ya. I can hear it now. "The Windows UI specs and the Apple UI specs say scrollbars should be permanent, now they are in Mozilla. What kind of crap is this? When did Mozilla decide to start honoring platform 'correctness'?"
dbaron, Theoretically your statement is correct and I agree but it does not help us much here I guess, i.e. we need something more powerful that adds weight or value in an analytical context. I am sure you can come up with something. I would like to see an analysis where the following 2 values are rated and a decision is made based on the outcome of this process: 1) Benefit of having a few more pixels of screen real estate in a very small minority of non-scrolling pages where this could easily be achieved by other means even with the Netscape 4 legacy browser. 2) Disadvantage of virtually disconnecting the internet user from their visual interface in a variety of cases, some of them documented in this bug, some of them in other related bugs. No successful workaround for this defect has yet been suggested here.
Jerry Baker, "What kind of crap is this?" Very interesting highly factual, analytical and qualified comment. What are you actually saying? Why are these UI standards crap. I would not want to follow standards blindly, but first one has to be able to ask questions e.g. what is particularily wrong with them and why one should ignore them i.e. alienating users who rely on their values.
I was making the point that sometimes people are a little overzealous in their pursuit of what they think is cool. They are willing to throw aside the user interface guidelines for the two most successful GUI's in existence because they don't like them. Who decides? I don't like some of the W3C specs, so why don't we ignore those ones too (for a good one look at the big oops with image alignment in the current box model). For some reason Mozilla has chosen to stick with the W3C almost to the letter, and without question. When it comes to the platforms that Mozilla operates on, it's an uphill battle to get Mozilla to behave the way applications are supposed to behave. I don't know why there is this need to follow standards for the Web, but to blatantly and flagrantly ignore standards for the various operating systems that Mozilla is distributed for.
Keywords: 4xp
I notice that you have all been quite carefully ignoring the specifics of my points in comment 83: | (a) The scrollbar is unsightly when the page doesn't require it. I find the disabled scrollbar in IE to be _really_ ugly. It detracts from the symmetry of many short pages. If authors want them enabled, I think they should have the choice, through an @rule or pseudo-element or something. (Or simply by placing invisble boxes everywhere they expect their page to grow to, so that the content never grows beyond what it started as -- this means that on large screens such as mine, those cases where the scrollbar isn't needed even when the dynamic animation is used won't needa a scrollbar at all.) | (b) The scrollbar being present on the window's viewport but not on an | <iframe>'s, <textarea>'s, <object>'s, or <img>'s viewport is internally | inconsistent. (This is much worse than being inconsistent with other apps | on the system.) This is a good reason to ignore the platform user interface guidelines. | (c) Other applications which display content (rather than displaying an | editor's view of the content) remove scrollbars when they are not | necessary, so that the user is not distracted by pointless UI. e.g. Powerpoint. This is evidence that even the people who wrote the guidelines are not always following them blindly. | (d) It makes no sense to have this behaviour for vertical scrollbars and not | horizontal scrollbars (and in fact this would be inconsistent with the UI | guidelines you quoted), and having disabled horizontal scrollbars is even | worse. (This point of view is even shared by WinIE, which disabled | vertical scrollbars but _hides_ horizontal ones.) Everyone has been carefully ignoring horizontal scrollbars. Why are they different? In a world of multi-directional text, why shouldn't we, by the argument given by people in this bug, have both scrollbars? That's what the guidelines are asking for. My answer: because it's really ugly. See (1). | (e) Pages which are special cases and will be frequently increasing | and decreasing their content (such as the demo I mentioned at the top | of this comment) should, IMHO, specify the viewport's scrollbar | settings themselves, and so should not be considered for this bug. I fully agree that there are some cases where authors need scrollbars when we're not showing them. Those are not common cases, but we should be taking care of them by providing ways for authors to control the scrollbars.
(a) So when are the criteria for whether to adopt a platform standard the ugliness of the standard as it appears to Ian? (b) But, I would argue, less so than flaunting custom when there is no standard requiring you to do so. People already expect browsers to behave this way. Changing it for no other reason than aesthetics is irresponsible I think. (c) Does Power Point shift centered or right aligned content over when it does this? IIRC Power Point is to develop presentations of slides in series. This is very much akin to the type of Web pages that are being disturbed by this bug. If PowerPoint made the position of right-aligned and centered text or objects dependent on the vertical heigth of page I would be very surprised. (d) Because it is of no consequence to page design whether horizontal scrollbars pop up or not. The only way it would be possible for this to be on the same level in the "annoying" factor, would be if it were possible that a horizontal scroolbar would shift content up on the page. AFAIK horizontal scrollbars just appear over content so they don't affect their position on the page, so no one cares.
aha@pinknet.cz: this is not 4xp. Navigator 4.x reserves the vertical scrollbar space but it doesn't show it when it isn't needed. Until summary is changed to "Web pages should always have vertical scrollbars by default or reserve their space", I 'm removing the misleading keyword.
Keywords: 4xp
Um. The whole point of this bug being filed originally was to have a static view port the way NN4 did and IE does. IE chooses to display the disabled scrollbar and NN4 does not. The effect is still identical.
I just checked and both NN4.x/Mac and IE5/Mac have dynamic viewports-- the vertical scrollbar appears and disappears based on the length of the page content-- so I think removal of the 4xp keword was justified. If you're going to continue ignoring non-Windows platforms in this discussion, and keep on spamming a closed bug, could you please at least switch the Platform/OS to whatever version of Windows you're using? That way those of us on non-Windows platforms can feel a touch more secure that, in the apparently unlikely event that this report gets reopened and actually worked on, we won't be annoyed by having Gecko break user expectations set by all the other browsers running on our platform(s). Thanks!
Fair enough. Platform changed. Compat keyword added. BTW - how do you specify the entire Windows platform?
Keywords: compat
OS: All → Windows XP
emeyer: But does NN4 reserve the space for the scroll bar. Just make a page with a white background, then a 100% width table with a black background. The Windows NN4 will show no scroll bar, but the right-hand 20 - 25px will be white because the 100% table won't go there.
your usage doesn't match the keyword's. i think we're using p-<sillyapp><sillyplatform> in the status whiteboard for parity markings. to mark a bug as for all windows, mark it for the oldest windows to which it applies (w95 usually). however this bug either will be fixed for all platforms or will not be fixed for any platforms, so it should not be marked as specific to one platform/os .
Keywords: compat
OS: Windows XP → All
Why would we want to lock Mozilla into one UI paradign for all platforms? Is there some overriding need in this case? I have to admit it seems like an underhanded way of accomplishing the goal of not doing this for no other reason than because a few have an opinion against doing it, but I may be mistaken.
Let me make a final statement for the record on this bug because it has become obvious that people are way too emotional about something that is really dumb to be emotional about, and so Mozilla won't change. This will sit here to be read by future people who get annoyed by the bug. There have been precious few arguments in support of Mozilla's current behavior except for plain personal opinion ("I like it" and "I don't like IE's permanent scrollbars"). Several rational arguments for Mozilla's current behavior have been made: 1) That there is precedence for this in other Windows applications such as Power Point and Windows Explorer. The problem with those precedents is that neither of those applications shift the content in the window to accomodate the scrollbars. Instead, the scrollbars overlay the content, and if this makes some content fall behind them then a horizontal scrollbar is added. Positioning is preserved, unlike Mozilla. 2) It makes no sense to have this behaviour for vertical scrollbars and not horizontal scrollbars. This isn't true. Vertical scrollbars displace content, horizontal scrollbars overlay content. That makes all the difference in the world. 3) It would be internally inconsistent to have the main browsr window with permanent scrollbars, but have iframes, images, textareas, etc. not have permanent scrollbars. This constitutes sufficient ground for ignoring the Windows GUI and Mac GUI specifications. This is the criteria? Says who? Where was that decided, and where are the discussions/minutes published for public review? Secondly, what makes it internally inconsistent? Just because Mozilla is a monolithic collection of iframes, textareas, etc. does not mean that it should behave that way. As far as the user is concerned it is a program like any other and it should act like one. A browser's canvas != iframe as far as the user is concerned. 4) Netscape 4.* didn't behave this way. Bzzzt! Netscape 4 behaves this exact way. It reserves the space for vertical scrollbars at all times. These are the only arguments brought in favor of Mozilla's behavior that do not involve subjective feeling and irrational opinions. Now, let's look at the arguments for permanent scrollbars. 1) The platform specifications for Windows and Macintosh specify that they should be there. 2) (a) The history of Netscape's behavior is to reserve the space for scrollbars (even when it didn't always display them), and as such there is no reason to break old behavior unless there is some compelling need (like standards compliance). (b) Internet Explorer on Windows behaves this way. Since about 90% of the world is using this browser to view the Web, again, why would we want to go and change the behavior that 90% of people are used to with no compelling reason? 3) Mozilla's current behavior makes consistent positioning of relatively sized right-aligned, and/or relatively positioned page content impossible. Meaning that it is impossible to maintain a consistent position of elements throughout a site even when the user does nothing more than browse from page to page (i.e., they never explicitly instruct their application to change the size of anything). 4) It is bizarre behavior for UI elements to pop-up over non-editable content and change the presentation of that content without explicit user instruction to do so (at least on Windows). Since some want to keep this bug platform universal, let's at least focus on the platform that Mozilla users are using it on the most then. Pro-change has platform guidelines from their respective manufacturer's, that 90% of the persons on the Web today are using a browser that behaves the way we are asking Mozilla to behave, that Mozilla users are likely to be former Netscape users and Netscape 4.* behaves in similar fashion, that Mozilla's current behavior forces anyone who wants to avoid this behavior (without hacks) to use fixed positioning and left-aligned pages, all going for it. The against change camp has that they think it would look dumb.
> 1) That there is precedence for this in other Windows applications such as > Power Point and Windows Explorer. > > The problem with those precedents is that neither of those applications shift > the content in the window to accomodate the scrollbars. Open "My Computer". Make the window short and shorter. Examine the pane to the left as the scrollbar appears and disappears. > 2) It makes no sense to have this behaviour for vertical scrollbars and not > horizontal scrollbars. > > This isn't true. Vertical scrollbars displace content, horizontal scrollbars > overlay content. That makes all the difference in the world. Horizontal scrollbars will quite happily displace content if the writing direction is top-to-bottom instead of right-to-left. > 3) It would be internally inconsistent to have the main browsr window with > permanent scrollbars, but have iframes, images, textareas, etc. not have > permanent scrollbars. This constitutes sufficient ground for ignoring the > Windows GUI and Mac GUI specifications. > This is the criteria? Says who? Me. Who says the criteria is blindly following UI Guidlines? > Where was that decided, and where are the discussions/minutes published for > public review? Since when do my opinions need discussions and minutes? > Secondly, what makes it internally inconsistent? A document in an <iframe> is going to bounce around just as much as a document in the browser. Now, let's look at the arguments for permanent scrollbars: > 1) The platform specifications for Windows and Macintosh specify that they > should be there. See arguments 1 and 3 above. > 2) (a) The history of Netscape's behavior is to reserve the space for > scrollbars The behaviour of other browsers is irrelevant, especially obsolete browsers. MacIE does the same as Mozilla, I am told. > (b) Internet Explorer on Windows behaves this way. IE does many stupid things. > 3) Mozilla's current behavior makes consistent positioning of relatively sized > right-aligned, and/or relatively positioned page content impossible. No it doesn't. That's nonsense. I've given several options already in this bug (e.g. making your template trigger scrollbars if required by making an element cover the area that dynamic content would enter), and have also said that I believe we should make this author-controlled for authors who really care. And secondly, I have yet to see a user who cares. This is an author concern, not a user concern, and users are the people I am most concerned about. > 4) It is bizarre behavior for UI elements to pop-up over non-editable > content and change the presentation of that content without explicit user > instruction to do so (at least on Windows). Since some want to keep this > bug platform universal, let's at least focus on the platform that Mozilla > users are using it on the most then. That's the same argument as 3. These are the only arguments brought against Mozilla's behavior that do not involve subjective feeling and irrational opinions. Despite your attempts at making the statement appear minor, a huge reason for not enabling vertical scrollbars all the time (or leaving room for them) is that doing so really ruins the look of many pages. Look at pages like: http://www.hixie.ch/tests/adhoc/css/background/01.html ...in Opera, a browser which leaves room: it looks unbalanced. Look at it in IE's full screen mode, a browser which shows a scrollbar (if you can get past the fact that it doesn't render the page correctly in the first place): it has a huge unsightly scrollbar down the right hand side of the screen. Pro-status-quo has aesthetics, precedents on all three platforms, that 100% of the persons using Mozilla are using a browser that behaves as the status quo, that Mozilla users are likely to be already Mozilla users, and that authors who really want their page to have scroll bars have multiple ways of getting them going for it. The against status-quo camp has that they think it sometimes shifts text a bit.
Blocks: 158464
Re: comment #c114 >And secondly, I have yet to see a user who cares. This is an author concern, not >a user concern, and users are the people I am most concerned about. I'm a user, I care. Sorry Ian. I'll spam my comments from a related bug that died a silent death: [ . . . ] I find it very annoying that the scrollbar isn't always there when browsing regular pages - for consistency's sake. For example, I'm browsing through pages that have the same layout, and I place my cursor over the "next" link so all I have to do is click the mouse. +------------------------------+ | Webpage - Mozilla | +------------------------------+ | | | [ previous | home | next ] | | | | | | lorem ipsum dolor sit amet, | | consetetur sadipscing elitr, | | sed diam nonumy eirmod tempor| | invidunt ut labore et dolore | | | +------------------------------+ This works fine as long as the subsequent pages either all show a scrollbar or do not. As soon as one page needs one when the previous didn't (or vice versa), the area available for content shrinks a little, and all content shifts right. (or left, in the other case). +------------------------------+ | Webpage - Mozilla | +-----------------------------++ | || | [ previous | home | next ] || | || | || | At vero eos et accusam et || | justo duo dolores et ea bla || | rebum. Stet clita kasd gub || | ergren, no sea takimata san || | lorem ipsum dolor sit amet, || +-----------------------------++ Often I find having to move my mouse again, eliminating the fast browsing. I did a search on "scrollbar" to make sure I wasn't duping - please forgive me if this load of anal retentiveness has already been posted by someone else. >Despite your attempts at making the statement appear minor, a huge reason for >not enabling vertical scrollbars all the time (or leaving room for them) is that >doing so really ruins the look of many pages. Look at pages like: [ . . . ] As a reply, I'll quote you again: >This is an author concern, not a user concern, and users are the people I am >most concerned about. Isn't your argument mostly an author concern? >[ . . . ] Look at it in IE's full screen mode, a browser which shows a scrollbar >(if you can get past the fact that it doesn't render the page correctly in the >first place): it has a huge unsightly scrollbar down the right hand side of the >screen. >The against status-quo camp has that they think it sometimes shifts text a bit. As above. It's not just that we only "think" it shifts, it *really* does. I swear!
> Isn't your argument mostly an author concern? Yes, since I was arguing against authors. The "next" thing is an issue, but that's what the link toolbar is supposed to fix. In practice, I see "next" links moving for many reasons other than the scrollbar, so I am nor in the least bit convinced that this would help much.
Attached file HTML Testcase (deleted) —
We ran into this when developing a site not yet released. This testcase illustrates the issue. Press the button to expand the submenues. When the table expands the scrollbars will appear. Toggling the submenu on and off will make the whole layout to jump.
_If_ the user opens all four menus, _and_ the page isn't taller than the content area, then, when opening the fourth menu, the page jumps. But then by that time the content is overflowing anyway, so the effect is lost. At least until you open the fourth item you don't have an ugly gray bar next to the menus.
Target Milestone: Future → M1
(Removing milestone which i accidentally set to M1. Thanks for the heads-up John.)
Target Milestone: M1 → ---
*** Bug 170971 has been marked as a duplicate of this bug. ***
I must really wonder how so many people making webpages could find it beeing a problem that Mozilla doesn't provide a scrollbar when it's not needed? Don't any of you know even some basic CSS? If you want a scrollbar in Moz, just add eg this to your page <div style="position:absolute; top:0; height:100%; padding:0 0 1px">&nbsp;</div> Guaranteed to give a scrollbar at all times, and that also happens to be 100% valid HTML/CSS (in short there is no need for even a special hack/ Invalid CSS to do it). Moz current implementation is the only 1 that give the webauthor the option to decide if he wants a scrollbar or not using NOTHING but VALID HTML & CSS. And an advice for next time, before wasting months on arguing about a nonissue, try to spend jsut 5 minutes to figure out that simple workaround that is already there...
Stefan, before people even contemplated about raising this issue in Mozilla their brains would have spent a few milliseconds only to reject the workaround you are suggesting. The very point of this bug is that there has to be predictability in dimensions without having to force a visible scrollbar with fake content exceeding available screen space as you are suggesting.
> there has to be predictability in dimensions without having to force a visible scrollbar with fake content Yes please, why don't we ignore all of the W3C specs and start adding huge heaps of proprietary code to mozilla. I'm sure that is the best solution... NOT And regarding it beeing fake content... it's examplecode... Replace that &nbsp; with eg <img src="sitelogo.png" ...> and suddenly it's not fake content any more but a tag to add your site logo to the page + CSS to create a scrollbar. You just have to think outside the box. The point here is, whith the current implementation it's a piece of cake to get your desired look as a webdeveloper with VALID CSS + HTML. Your suggestion however forces the use of proprietary/invalid CSS. I'm sure it's pretty obvious which is the better solution.
*** Bug 155092 has been marked as a duplicate of this bug. ***
*** Bug 186381 has been marked as a duplicate of this bug. ***
*** Bug 187553 has been marked as a duplicate of this bug. ***
*** Bug 204649 has been marked as a duplicate of this bug. ***
*** Bug 209480 has been marked as a duplicate of this bug. ***
Internet Explorer 6 has persistant vertical scrollbars. Stefan: Can you please point to where in the CSS specs it says that a persistant scrollbar like IE 6 has is invalid? The XUL frame of the HTML document is the viewport and defines the initial containing block. It says (http://www.w3.org/TR/REC-CSS2/visuren.html#viewport): "When the viewport is smaller than the document's initial containing block, the user agent should offer a scrolling mechanism" Then look at: http://www.w3.org/TR/REC-CSS2/visufx.html#overflow If you look at the intent of this, by reading the section labelled scroll: "This value indicates that the content is clipped and that if the user agent uses scrolling mechanism that is visible on the screen (such as a scroll bar or a panner), that mechanism should be displayed for a box whether or not any of its content is clipped. This avoids any problem with scrollbars appearing and disappearing in a dynamic environment. When this value is specified and the target medium is 'print' or 'projection', overflowing content should be printed. " This seems to suggest that you should show a disabled scrollbar in that case. So where does the specs say that the BODY element can't have "overflow: scroll" by default? The way that Mozilla causes the page dimensions to change is unattractive and unreliable when changing pages. There is no penalty for having it always present except for about 10 unused pixels on the screen as opposed to possible unattractive bouncing around of content on pages based on how tall they are. Various people mentioned a user can override this for the body element, but that doesn't help when you are crossing site boundaries with different authors (Such as Excite -> Google). If writing direction is top-down as Hixie mentioned, then you replace [vertical] in this bug with [horizontal]. As for textareas, IE 6 has permanent vertical scrollbars, and that makes sense, also as you don't need the area of what you can type in to change at the point you go beyond the bottom. In fact, the appearance of a vertical scrollbar will in some cases necessitate the appearance of a horizontal scrollbar that wasn't already there. In fact, you can test this in Mozilla. Pick a textarea with wrap = off, and then use up all the horizontal space per line, but not enough to cause a horizontal scrollbar. At the point you go past the bottom, both scrollbars appear! This enhancement request has 9 votes and a ton of dupes, and doesn't appear to go against the specs (or no proof to the contrary has been stated). Therefore, I feel it should be reopened.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: Web pages should always have vertical scrollbars by default → Web pages should have a persistant scrollbar for all pages
This "bug" is not going to be fixed. It is a conscious design decision. The people in control have made their position very clear. Life is short, you need to pick your battles wisely, and this is not one that you can win. So let's please leave this bug alone. If you want a scrollbar on your pages, as I do, there are plenty of solutions. Just pretend that there is no way in hell that Mozilla will change, and use a workaround. My personal favorite is the following, which doesn't trigger a one- pixel scroll in IE: CSS - #mozscroll { position: absolute; top: 0px; bottom: -1px; visibility: hidden } HTML - <div id="mozscroll">&nbsp;</div>
I am not taking a web author position, but that of a user (even though I'm a developer). Its not up to the developers or web author what the user sees, and the user cannot force the web author to add CSS to their page. I do not see this as a standards breach, and is something that will make Mozilla appear to have a cleaner interface for the user. Mozilla is a community, and a meritocracy, and I am throwing some weight behind this feature request so there can really be a validation of whether or not it breaks the standards, or is it simply an issue of individual developer preference. If its simply a case that developers don't want to do it, then I'm sure there are others that would be willing to take it. I would be willing to take it, for instance. If its a case of a reason with sound basis in standards done for principle, then I will be willing to accept that and will be at least satisfied it got the proper consideration. At which point, it would be better taken to the newsgroups for further discussion. My main question is: Does it break standards for the initial containing block to have persistant scrollbars (enabled or disabled depending on the length of the page)? If so, what portion of the standard does it break (URLs)?
This bug will not be fixed, but we will be introducing ways of letting Web page authors (and users, through user stylesheets) control this, so settle down people, your needs will be addressed! WONTFIX.
Status: REOPENED → RESOLVED
Closed: 22 years ago21 years ago
Resolution: --- → WONTFIX
-> Verified Ok, cool. The user stylesheets would handle the user side of wanting this feature. I do hope it in the user stylesheet by default, though, and W3C decides that's the default behavior. It just seems like a cleaner interface with the scrollbar always there. :-)
Status: RESOLVED → VERIFIED
IMHO, scrollbars should be invisible by default, but web developers should have a method to force them to show or hide. I.e. something like body {scrollbar-horizontal: visible; scrollbar-vertical: hidden} Of course, you can object to it that it doesn't comply with current CSS level 2, but I think if there's a true need in it, mozilla developers should take an initiative and suggest W3C to make this extention in CSS 3. Unfortunately, CSS 3 will not ne done soon, so this extension should be incarnated before it, BUT in exacly the same way. as it will be in final CSS 3.
> Unfortunately, CSS 3 will not ne done soon, so this extension should be > incarnated before it, BUT in exacly the same way. as it will be in final CSS 3. How exactly are we supposed to know what CSS3 will say before CSS3 is released? Anyway. See comment 132.
It wouldn't matter anyway...no one at Mozilla wants to implement standards that they have personal issues with anyway: "Mozilla - it's better than standards compliant, only *cool* standards compliant!"
What I see in this bug is mozilla people rejecting this bug without any real reasons. I see a lot of compelling reasons by a lot of people why this bug /should/ be fixed, but it's marked as WONTFIX. It's too bad and funny at the same time.. mozilla's suppose to be following standards yet it's breaking simple web page layout all over the place.
i'm a firebird newb, so when i first encountered this issue, i thought it was my own sites causing it, and looked for hours on what might be the problem. asked on firebird forums and was told it was intended to be this way in the browser itself. i don't get the logic behind this, as some describe in the comments, for sites where some pages are long and some are short, the entire page shifts around, back and forth, it's extremely displeasing to the eye and comes across as a bad bug. as silly as it may sound, i don't think i would want to endure having to see the page bounce back and forth by 20+ pixels all the time, might just be easier to switch browsers again. dissapointed if there will be no resolution of this.
Hixie mentioned in comment 132 that CSS3 will give authors a way to control this (and I hope that the scrollbars being always visible is the default on graphical user agents :-) )
Non-persistant scrollbars in forms also means that forms' wrapping changes when you go beyond the bottom of the form. If you look at word processors, they have persistant scrollbars. I believe that the CSS option should be to turn off persistant scrollbars instead of on. Persistant bars seems to be the most desirable behavior.
*** Bug 225608 has been marked as a duplicate of this bug. ***
*** Bug 226446 has been marked as a duplicate of this bug. ***
*** Bug 237257 has been marked as a duplicate of this bug. ***
*** Bug 238172 has been marked as a duplicate of this bug. ***
*** Bug 245662 has been marked as a duplicate of this bug. ***
To comment 83: Others have supplied with samples. Here you have another set: http://www.sonnd.com/mozilla/persistent_scrollbar.html And real life: http://www.informationmechanics.com/ In this site we had to extent the length of every page to make sure Mozilla wouldn't ruin the design. To comment 88: "Oh come off it. Like users are going to notice that. The home page looks better when it has no scroll bars, anyway. Big deal." I do, often enough. And have had to fix this for sites we have don't. Fix it for Mozilla, that is. IE and now Safari, don't have that problem. David Hyatt implemented this for Safari 1.2 To comment 99: "Note that the people who would be annoyed if the behavior were what you want aren't angry about it and aren't adding tons of commentsto the bug." That majority would still be a minority among users. They would have to be mainly users of Mozilla with no regard for the majority of IE users. To comment 104: "I find the disabled scrollbar in IE to be _really_ ugly." A question of taste, with which I do agree. But doing websites for a living I rather have what IE offers. I can disable it whenever I want by <body scroll="no">, as long as content doesn't exceed viewport height. An @rule would be a solution, but given IE5.x, IE6 and Safari's general use, we might as well do the same and allow site owners to remove it, instead of adding it. This would not allow you to avoid seeing that scrollbar in the majority of pages... guess that's were you see the problem? Your mention of Powerpoint can be confronted with the mention of IE and Safari. Far more relevant if you ask me, since we are talking browsers. With horizontal scrollbars you are talking about possibility rather than probability. Taking possibility as a factor for UI issues makes no sense (it makes no sense for mostly everything under the sun, with the possible exception of security issues). The probability of the scrollbar appearing on a random page must be orders of magnitude smaller than the vertical one, which usually changes within the pages of the same site. And to comment 132: "so settle down people, your needs will be addressed!" What about we fix it and then you open a bug for your needs to be addressed? ;)
Seeing all the crap people buy in stores nowadays, I'm beginning to think people care more about how things look and cutesy things than a lot of other things, such as quality and security. Little details like this drive some perfectionist web users crazy. Not to say that Mozilla should abandon quality, but we should also think about what the average user looks for, and its not security or standards' compliance, its cutesy little details that a power user usually wonders, "Why did they waste their time on that?"
OK. I admit that with the long thread, I scanned through it, but here's a suggestion: why not have the scrollbar enabled/disabled by a simple checkbox in the browser options. Personally, I would leave it on for myself and my clients, but those who live by browser compliance can turn off the checkbox to allow the bar to have the scrollbar come and go. Now everybody can be happy.
One more tidbit. It's stuff like this that keeps that garbage browser MSIE with 95% market share. Mozilla would get better acceptance by regular users if we followed MSFT's tactics of embrace and extend. If Mozilla could do EVERYTHING that MSIE could do (except browser hijackings, pop-ups, and system compromises) your average user would have no reason to use MSIE. I do 99% of all my browsing on Mozilla nightly builds but there are a few sites that force me to use MSIE.
Could we have something like -moz-persistant-scrollbar: disabled|enabled?
***** PREAMBLE The main problem about this thread is that people who wants permanent scroll bar will read my comment and will agree with me, but those who don't want permanent scroll bar will not even read my comment because they are fed up to see comments about this. It seems that those who makes decisions here are the people who don't want permanent scroll bars and they won't hear they users anymore on this subject. So I have the feeling that my comment is really pointless. I have another feeling than even if we can prove that 90% of the users wants permanent scroll bar, anything will be done either. I think that the "Open source - Closed mind" behavior should stop and that we should find a solution that will please everyone. END OF PREAMBLE ***** The scroll bar should be always visible. I have to say that the argument of the people who wants scroll bar only visible when page is too long is not a good argument at all. The scroll bar is a part of the browser, not the website. All the website url's that were posted as example of "why mozilla shouldn't display scroll bar" didn't convinced me at all. If the scroll bar is always there, the user sees it as part of the program and not the website, then the user makes an abstraction of the scroll bar when looking at a website. People progressively uses more css than before. And a lot of people find it more easier to make fixed width layouts using css than extensible layouts, so we have to expect more and more centered fixed width layouts to come. And if anything is done, this thread will continue to grow for years. I talked to a lot of webdesigner about this thread, all of them does agree that the vertical bar should be always visible. The current behavior of mozilla about the scroll bar is very irritating. You should see the number of times I'm irritated when surfing on a centered website, with multiple pages that I browse quickly (such as results of a search or something) on which there's a "Next" button for the next page. I put my mouse over the "Next" button and click on it --> page2 then I click again --> page3, ... then I click again quickly but the Xth page is longer than the other pages, so the scroll bar appears and the whole site is moving on the side and the mouse is not over the "Next" button anymore. This is an example of the practice side, but the problem is also esthetic, the problem is far more annoying than the pseudo problem people say that it would cause if mozilla would keep the scroll bar on the side. Anyway, I think the better option would be to keep the scroll bar always visible and leave an option for the rare people that prefer to have the scroll bar only if the page is long. And I repeat it again : there is more people that would prefer the scroll bar to be always visible. And the majority of people that don't know anything about this thread are people that would prefer the scroll bar to be always visible. I tried some workarounds that were given in this thread, and I had problems with them (I can't remember exactly but I can check again) Anyway, these workarounds are not interesting in this context, because most of the websites are done by people that even don't check on other browser than IE and most of them don't know anything about this thread. The result is that even if the workarounds were working good, it would be used only by a small amount of people who produces web-sites. The final result is that this will always be an argument against mozilla from IE users. Those who check their centered website on mozilla will just post a duplicate of this bug and will land here in this thread, disapointed to see that nothing will be done. PS: I'm sorry about the "Open source - Closed mind" remark. It is a very bad remark and I don't really think this. It was just a trick to force people to read this comment until the end ;-) So please forgive me about this and forgive me about my bad english.
It should be nice if someone wrote an extension (xpi) for this. Although I wonder what layout incombatibilities it would induce on fixed width pages.
If it creates layout problems in pages, then they haven't tested them in IE.
I always say developers should leave information for things they'd like done but aren't going to do themselves. I will therefore stick true to my words. Here are some implementation details: XPI would not be the route to go on this. There should be moz-* CSS properties for this, such as: -moz-scrollbar. Then you could hack it into your userchrome.css html {overflow: -moz-scrollbars-vertical} doesn't seem to do what we want. In fact, it appears broken when I fooled around with it. The scrollbars didn't go the entire length of the page. Why don't we add: scrollbar-y: -moz-always-on | auto | -moz-always-off scrollbar-x: -moz-always-on | auto | -moz-always-off It also needs to be greyed out when shown but not used. You'll need to create a new property, and break up the overflow implementation into x and y, but still honor the existing overflow property. This should go into XPCOM http://lxr.mozilla.org/seamonkey/source/content/shared/public/nsCSSKeywordList.h <- mapping to identifier http://lxr.mozilla.org/seamonkey/source/content/shared/src/nsCSSProps.cpp <- mapping to XPCOM identifier macros http://lxr.mozilla.org/seamonkey/source/layout/base/public/nsStyleConsts.h <- Identifier macros defined http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsGfxScrollFrame.cpp#640 <- Example implementation http://lxr.mozilla.org/seamonkey/search?string=mOverflow <- All implementations http://lxr.mozilla.org/seamonkey/source/content/shared/src/nsStyleStruct.cpp#1069 <- Define scrollbar-y and scrollbar-x in nsStyleDisplay http://lxr.mozilla.org/seamonkey/source/content/shared/public/nsStyleStruct.h#734 <- Define it also in header file When this is finished in CSS3, we'd only need to modify the code a bit (add aliases to the identifiers and to the property) if we already had this hacked in. Good luck in implementing to whomever decides to take this on.
Ignore comment 154. CSS3's proposed overflow-x and overflow-y properties are sufficient.
David: Did you read my comment? If you are planning to rewrite the entire CSS code of Mozilla, you should say so, otherwise I wouldn't advise people implementing a patch to ignore the entire comment #154 unless they have memorized the code locations. Most of it is still relevant regardless of what the spec is, only a few things need to be changed. overflow-x would still be placed in the nsStyleStruct interface. Since you seem to suggest that a slight modification needed in a comment requires ignoring the entire comment, here is a rewrite mentioning the CSS3 properties that I didn't realize were formalized yet: I always say developers should leave information for things they'd like done but aren't going to do themselves. I will therefore stick true to my words. Here are some implementation details: XPI would not be the route to go on this. Use overflow-x, and overflow-y, which is part of the CSS3 recommendation. http://www.w3.org/TR/2002/WD-css3-ui-20020802/#overflow-x This should go into XPCOM http://lxr.mozilla.org/seamonkey/source/content/shared/public/nsCSSKeywordList.h <- mapping to identifier http://lxr.mozilla.org/seamonkey/source/content/shared/src/nsCSSProps.cpp <- mapping to XPCOM identifier macros http://lxr.mozilla.org/seamonkey/source/layout/base/public/nsStyleConsts.h <- Identifier macros defined http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsGfxScrollFrame.cpp#640 <- Example implementation http://lxr.mozilla.org/seamonkey/search?string=mOverflow <- All implementations http://lxr.mozilla.org/seamonkey/source/content/shared/src/nsStyleStruct.cpp#1069 <- Define scrollbar-y and scrollbar-x in nsStyleDisplay http://lxr.mozilla.org/seamonkey/source/content/shared/public/nsStyleStruct.h#734 <- Define it also in header file Good luck in implementing to whomever decides to take this on.
"only afew things need to be changed. overflow-x would still be placed in the nsStyleStruct interface" in the above comment should read: "only a few things need to be changed. overflow-x and overflow-y would still be placed in the nsStyleStruct class" Also, replace "implementations" with "references to mOverflow that can show you where to put mOverflowX and mOverflowY references". See also bug 76197 (mentioned earlier but hard to find) - Scrollbars should look disabled when there's nowhere to scroll. Should all further discussions about the implementation of this aspect of CSS3 be discussed in bug 76197?
Depends on: 72747
Generally the people explaining how things should be done should be the ones who know what they're talking about. Please don't clutter this bug with more than it needs. You're explaining how to do the easy part without explaining how to do the hard part, which really doesn't help very much.
Never mind that this bug is WONTFIX, which means we're not interested in a patch. (We would be interested in a patch to implement -moz-overflow-{x,y}, but that's a topic for another bug.)
(In reply to comment #159) > Never mind that this bug is WONTFIX, which means we're not interested in a patch. See http://slashdot.org/articles/04/06/06/136235.shtml?tid=126&tid=154&tid=95#9350109 for people's impressions of that attitude.
Re comment #151. Logic does not apply here ... What Fabien is describing is very true, and the annoying bit applies to many humans in general. There are a lot of people who make decisions too easily because they argue with a type of logic where they choose to ignore 90% of the facts, maybe because they think they are more qualified in their field of experience than others. The fact that "Democracy" or "Open Source" is applied as an additional layer to this anti-logic only obscures the lack of openness. On the side of those who wish to maintain the status quo in Mozilla, there is a disturbing lack of plausible facts in any arguments. In act all facts are avoided as much as possible. The arguments are highly opinionated and egocentric. This is about more than scrollbars. This is about how it is possible that the truth, which is in this case is so easily available, and by the way is clearly reflected in the number of duplicates and in the number of complaints in this bug, can be easily defeated by hairsplitting and bureaucracy. I can clearly see that thowse who downright refuse to accept patches that would fix this issue do not act in the interest of the majority of users. This has been stated often enough and with undisputable arguments here. I have experienced this in Mozilla more than once but there is nobody to talk to who has both enough influence to change things and at the same time has the capacity to analyse the problem in its entirety. In this case, it is extremely obvious because none of the problems that exist because of this bug have been addressed in a way that is compatible with existing pages and the industry standard browser, which is - as much as I am sorry to say that - Microsoft Internet Explorer. The argument that an equal or higher number of dissatisfied users would exist on the opposite side if this bug was fixed is extremely weak. I think it must first be supported by some evidence before it can be taken seriously: There are other browsers that do have bug recording systems and that emulate IE's behavior. Where please are the requests for the removal of the persistently reserved scrollbar space in any of these browsers?
Yep, I agree with the latest comments. There has been far too many reasons, examples and people FOR fixing this bug. There has been a large amount of support, reasons and people giving detailed reasons why this bug should be fixed. The people that think this bug shouldn't be fixed simply haven't given any solid reasons why it shouldn't. For this reason I've given up spending my time reporting bugs to mozilla. I think some of the moz developers have some really bad attitudes and should be listening to the people that speak this loudly on bugs. Maybe it's attitudes like this that made people branch off from the XFree86 project.
Look, I don't care about the core team's personalities or any of the political **** that always goes on in a development project. There is a compelling and logical reason why this bug must be fixed and why WONTFIX is not an acceptible outcome: The width of the canvas should not depend on the amount of content to be displayed. It defies all common sense that the canvas width could change depending on how much text is in a document. And it is a serious user-interface issue when performing a /vertical/ resize of a window can change the /horizontal/ positioning of objects. IE understands this. Safari understands this. Opera understands this. Even NN4 understood this - the canvas width was specifically preserved by a background-filled area which took the place of the invisible scroll bar. It doesn't have to be a scrollbar. It can be anything that the Moz developers want, from a solid black box to a tiled strip of dancing hamsters. But something needs to be there to preserve the width of the canvas. I pointed this in comment 97, and yet the debate is still in exactly the same place today as it was two years ago. Until this issue is acknowledged as a serious problem, the Moz devs have no right to talk about usability or interface consistency.
Two reminders: * Open-source does not imply democracy. In fact, democracy as a method of software development is generally a bad idea. * Most of the comments on bugs with lots of advocacy come from people who want the current behavior to change.
(In reply to comment #164) > Two reminders: > * Open-source does not imply democracy. In fact, democracy as a method of > software development is generally a bad idea. I know exactly what you are talking about. I know that talking for age about a dev topic can slow down a project. I know that this thread is the lowest priority of the mozilla dev team, but I wish it won't because I believe it is not a little bug to store in the whishlist. I know that users won't stop complaining about everything and I know that from a developper's view it quickly become irritating. I think I won't post comments anymore about this because I respect your work too much and I don't want to become irritating and I don't want to loose your time, so the last thing I want you to know is that WE (I think I can speak for the majority of people in this thread) are fighters ;-) I'm explaining myself : I'm not involved in the mozilla development, but I constantly fight trying to convince people to use mozilla instead of IE. I'm using Linux at home but everyone at my office uses IE except a few that I already converted. My "mozilla-converter" speech is ready at anytime of the day, everytime I have the opportunity I use it trying to convince someone to use firefox instead of IE in 5 minutes. As most of my colleagues are web developper, I start to show them how tabs are usefull, how some XPI such as Web-Designer, LiveHTTPheader, EditCSS, are essential tools, I show them how easily they can browse their cookies, I explain how IE + Outlook is a open Window(tm) to viruses and trojans, and how Firefox + Thunderbird is much safer... in short, I show them how mozilla is a THE browser to use. But when they give mozilla a try and they see the problem related to this bug, I must admit that I'm out of argument and I guess I'm not the only one. So you can see that even if I'm not involved in mozilla development, at my little level, I keep trying to make mozilla more used around me, and I wish (as everyone here) that mozilla will get better and better. This is the reason why I posted these comments so far, and I hope that this problem will be fixed one day, so I will know that the next people I'll switch to mozilla will be 100% pleased of this excellent browser. Regards.
In all fairness, David Baron is qualified to make decisions because he knows a lot about the standards because he frequents the mailing list discussions... This IS in the specs, though! This reminds me of the table backgrounds not being rendered without content in it bug back a couple years ago that wasn't fixed for a year after someone mentioned that the spec errata told us to fix it. There were still strong hackers giving arguments against fixing it regardless of it being in the specs. That, imho, is ALL that matters! Its been fun, but its right there: http://www.w3.org/TR/2002/WD-css3-ui-20020802/#overflow-x Any advocacy for or against is moot from this point on, aren't they? With that being said, David: > Open-source does not imply democracy. In fact, democracy as a method of software development is generally a bad idea. > Most of the comments on bugs with lots of advocacy come from people who want the current behavior to change. Response: 1. My comment 154 and comment 156 was not advocacy, it was patching details that might mean diddly squat to strong hackers of Mozilla, but allows people to decide whether they want to tackle this for their first patch (or second, or third...). See bug 114760 where I describe what I'm talking about. 2. I sure hope it changes or we won't be supporting CSS3, will we? 3. I agree this attitude is not the way to win users and praise from the web community. I know where you are coming from on the advocacy thing, but a "Take this to the forums" would at least allow people to disucss it and get their voices heard by project members. What you said ignores the fact that overflow-x and overflow-y are already in the recommendations. You already said it was. Can they not be adopted prior to adopting other aspects of CSS3? Is overflow{x,y} going to change significantly within the CSS3 recommendation? I highly doubt it. We can implement -moz-overflow{x,y} and later alias it to overflow-{x,y}. If I remember correctly, our CSS2 adoption, it was piecemeal. And if there is no bug for the -moz-overflow{x,y} to officially discuss IMPLEMETATION details, why not? This issue CAN'T be WONTFIX any more in the general snese because overflow{x,y} IS in the standard, isn't it? Either this bug most be reopened, or it must be handled in a separate bug. Take your pick, will it be this bug, bug 76197, or a new bug? As for the information I gave... It WOULD be useful to someone writing their first patch (or second, or third...). What I submitted on this bug would not be easy for a 3rd party developer to figure out in a short amount of time after they build Mozilla the first time. Perhaps this isn't the kind of thing someone with no experience on the Mozilla project should be tackling as their first bugfix, but who are we to say? True, I found that stuff in like 10 minutes, but it could take other people days to figure out. We could use a patch for the -moz-overflow{x,y} and why should we limit the source of that patch to people who have been on the project for 3 years? Module owners and patch writers who are not planning to fix a bug right away SHOULD take the 10 minutes required to give a quick summary of how to fix bugs so that 3rd party people can decide whether they have the time to fix a bug -- and this is the biggest thing. Sure, many developers have the skills, but don't have the experience in the Mozilla project and a simple discussion of what's needed in each important bug can give them an idea of whether they should tackle it or not. So do we wait 5 years for this CSS3 aspect to be adopted, or give patchwriters more information on how to solve it? Remember there are not even close to as many mail developers on this project as their used to be. Coming from my patch writer's standpoint, I really don't see the harm in a patchwriter implementing -moz-overflow-x, and -moz-overflow-y and from my web developer's standpoint, this would be great and give them the same kinda flexibility they have for other things like -moz-pre-wrap.
Let's get this discussion off of Bugzilla. I opened a thread to further discuss the default value of overflow-x and overflow-y at http://forums.mozillazine.org/viewtopic.php?p=569350#569350 I'd like to simply mention that overflow-x and overflow-y are in the specs for CSS3 as David pointed out: http://www.w3.org/TR/2002/WD-css3-ui-20020802/#overflow-x Therefore, the only thing that is up for debate, it seems, is what the value of those two properties are by default. That is off-topic for a Bug report (this isn't a thread or newsgroup but a bug reporting tool) and should be moved to the forums. overflow-x and overflow-y being implemented will probably be handled in a different bug. The default value will, I imagine, remain such that behavior is consistent by default with how it used to be. Therefore, discussion should be taken to the forums on what the default value is. That I don't see a default value mentioned in the specs (without having paid attention to a bulk of the discussion on the CSS list) would lead me to assume that there has been no agreement yet over a default value. Makes sense, as it should be decided on a browser-by-browser basis. Therefore, for futher discussion on the default, head to -> http://forums.mozillazine.org/viewtopic.php?p=569350#569350
Whiteboard: Take discussion to the forum topic 569350 at the above URL
The default value for those properties is 'visible' and must stay that way ever for the root element in order for 'overflow' propagation from both HTML and BODY to work. And please stop confusing "how to 'fix' this bug" and "how to implement those properties".
I am just designing a browser based user interface. In the left frame, the content length might change, depending on user clicks on table cells in that frame (caused by dynamic font size changes). How utterly funny and stupid this looks when the user clicks on one cell, and then the same cell jumps away from the mouse position when the scrollbar appears/disappears! Imagine you want to test drive a car and the salesman insists you must wear soap solution or massage oil on your hands for that. When you object, then he pulls out his ISO standard sheet and says: Para 97-k77, standards-compliant, WONTFIX. Of course you go. Mozilla is very much like that. Good luck driving! Needless to mention that we advise our users not to use Mozilla/Netscape 7.
The whole thread comes down to usability versus standards compliance. I understand the logic for standards compliance. However, this is such a glaring issue to Mozilla newbies that it is a MAJOR factor inhibiting its general acceptance. I have put several clients on Firefox and frequently I get requests to shift back to MSIE because the web pages don't look right under Firefox (or Mozilla). I hear "It looks right in MSIE. Why doesn't it in Mozilla (Firefox)?" End clients are more concerned about the operation of a business than a whole explanation of why it wont work right because of a technical standard. At their request I shift them back to MSIE. Future clients, I have to give them a verbal disclaimer telling them that things might not look/work "perfectly", which is pretty tough to "sell" a "broken" product to a business owner. I bet I could get 25% more of my clients to continue to run Firefox/Mozilla IF I HAD THE OPTION to set the scroll bar to the permanent "on" position. Everybody would be happy if we had an option to manually turn on/off the scroll bar at the browser. Those that want strict browser compliance can leave it off. Those that deal in the world of asthetics can turn it on. It would be an EXCELLENT solution instead of just walking away at the expense of the Mozilla project.
Re: Comment #170 I agree, it would be a great solution for everyone, but I think the people in charge are just being stubbern and defient. Just look at some of the silly things they have as user optons: - Show the about page as a popup or not - Show emoicons in mail messages - Make mail and newsgroup messages quoted with graphical lines They don't care about major concerns such as web page layouts shifting around and breaking the athstetics of a web-based UI, but they'll make damn sure they get those smiley faces in the mail client... Rediculous.
Stop trolling in a closed bug, or your bugzilla accounts will be disabled. Take it to the forums or newsgroups.
Why is this bug marked as a wontfix when there is so many votes and people that want it fixed?
(In reply to comment #170) > I hear "It looks right in MSIE. Why doesn't it in Mozilla (Firefox)?" End Are they complaining about the issue in this bug? If not, then the comment is irrelevant to this bug.
I'd like to re-iterate that if you post on mozillazine you will be heard. http://forums.mozillazine.org/viewtopic.php?p=569350#569350 So far only one person has made a comment. Let's have some discussion there.
(In reply to comment #174) > (In reply to comment #170) > > I hear "It looks right in MSIE. Why doesn't it in Mozilla (Firefox)?" End > > Are they complaining about the issue in this bug? If not, then the comment is > irrelevant to this bug. Usually yes. Which seems to be the theme of the whole thread. If I have a client wanting to move off of MSIE, it is because he uses too many "MSIE only" web sites (like advanced features in msn.com) OR because he is getting too many layout problems under Mozilla/Firefox when the scroll bar appears/disappears. I have access to web logs of about 85 web sites and ~95% are using MSIE. Hmmm. Why is that? The people keeping this in a VERIFIED WONTFIX status or the people wanting to censor the comments by dropping us out of bugzilla (comment #172), I think they propose that it would be easier for us to contact the design firm of every web site we find and have them bring the site to conform with the web standards at the time and expense of the company. Many solution providers find it easier to keep the client on MSIE. At least I am trying to convince clients that MSIE is a lame browser that invites a host of security/privacy problems and the solution lies with Mozilla/Firefox. I find the price the Mozilla orginization pays is that solution proivders (and evangelists) like me slow the recommendation and implementation of Mozilla/Firefox because of this issue and others like it.
(In reply to comment #175) > I'd like to re-iterate that if you post on mozillazine you will be heard. > http://forums.mozillazine.org/viewtopic.php?p=569350#569350 > > So far only one person has made a comment. Let's have some discussion there. I'm there....
*** Bug 251683 has been marked as a duplicate of this bug. ***
*** Bug 256879 has been marked as a duplicate of this bug. ***
*** Bug 265864 has been marked as a duplicate of this bug. ***
*** Bug 269411 has been marked as a duplicate of this bug. ***
No longer blocks: 158464
*** Bug 285421 has been marked as a duplicate of this bug. ***
*** Bug 265864 has been marked as a duplicate of this bug. ***
Summary: Web pages should have a persistant scrollbar for all pages → Web pages should have a persistent scrollbar for all pages
*** Bug 293723 has been marked as a duplicate of this bug. ***
*** Bug 294087 has been marked as a duplicate of this bug. ***
I have tried my best to thoroughly read this thread and the associated forum thread produced from it. However, and I mean absolutely no harm in doing this, I again would like to bring up a place here to vote for the option to have permanent scrollbars (not within iframe, but just in main window/tab in Mozilla/Firefox/etc itself (via Tools->Options->Advanced) in a future release for the developer willing to take it on. If it is marked as "WONTFIX" then people probably will not vote on it, so no one will know how important it is to the user community. I am not emotional about it (really), but I think it is in the best interest of the user experience to bring this up again in bugzilla. I do this solely from a user's perspective. I heard a few users last week complain about it to the point where they won't use it. If our office is a microcosm of society in any way, I will assume there are a number of others out there (more than the 13 who have voted on this bug) that would use Firefox, etc. if this option would be implemented (and I might suggest, have this functionality by default). Please understand that I have read the request to take this comment to the forum, but my comment relates specifically to this "bug" which is really a request for new functionality which will seem to require significant work, but will pay off the effort in a larger user community.
I currently use "body {overflow-y: scroll;}" to force the vertical scrollbar in browsers that support it. This effectively makes the issue a moot point, no?
(In reply to comment #187) > I currently use "body {overflow-y: scroll;}" to force the vertical scrollbar in > browsers that support it. This effectively makes the issue a moot point, no? I do this too. However, not all user groups that Firefox (supposedly) targets have the knowledge or skills to use "body {overflow-y: scroll;}" while they browse. Is Firefox a web browser for IT professionals and CS majors, or a web browser for mere mortals too?
*** Bug 351851 has been marked as a duplicate of this bug. ***
Attached image eye problem caused by this. (deleted) —
My eye goes to left a little when I change from a short page to a long page. The default vertical scrollbar is good to usablity.
Attached file Work around (deleted) —
Attached a short userContent.css file to be placed in your profile directory that will fix this using the method above.
*** Bug 279425 has been marked as a duplicate of this bug. ***
*** Bug 360476 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: