Hixie (not reading bugmail) ian@hixie.ch 2001-03-19 13:54:48 PST
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.
David Hyatt hyatt@mozilla.org 2001-03-19 15:54:51 PST
Never mind. Thorough profiling and jrgm's tests show that this is not a
problem.
Erich 'Ricky' Iseli Erich.Iseli@iseli.org 2001-04-24 12:56:21 PST
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.
David Hyatt hyatt@mozilla.org 2001-04-24 13:24:41 PST
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.
Joe Hewitt (gone) hewitt@formerly-netscape.com.tld 2001-05-01 15:05:56 PST
hyatt told me he didn't need this after all
David Baron [:dbaron] dbaron@mozilla.com 2001-05-01 15:18:23 PST
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.
Joe Hewitt (gone) hewitt@formerly-netscape.com.tld 2001-05-01 15:33:45 PST
sorry, I didn't read all the comments.
Jesse Ruderman jruderman@gmail.com 2001-05-02 16:29:08 PST
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>
Matthew Paul Thomas mpt@myrealbox.com 2001-05-05 23:47:09 PST
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.)
MauiNui mozilla@mauinui.com 2001-08-05 22:56:15 PST
Created an attachment (id=44769) [details]
or, base the page alignment on frame instead of frame+scrollbar/lack-thereof?
Attachment:
This is the #1 annoying bug for me, since I have a site (not up yet)
which suffers pages being recentered due to the presence (or lack) of
the page scrollbar.
Would it be possible to fix this problem by basing the alignment
strictly on the frame, instead of frame+scrollbar/lack-thereof? That
might be a better compromise for those who don't want a scrollbar on
short pages. Navigator 4.77 solves it this way.
bht@actrix.gen.nz 2001-08-29 00:03:27 PST
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.
David Baron [:dbaron] dbaron@mozilla.com 2001-08-29 07:05:24 PST
> 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.).
bht@actrix.gen.nz 2001-08-29 12:43:07 PST
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!
David Baron [:dbaron] dbaron@mozilla.com 2001-08-29 13:28:32 PST
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.
bht@actrix.gen.nz 2001-08-29 14:11:32 PST
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.
Hixie (not reading bugmail) ian@hixie.ch 2001-09-29 09:48:20 PST
bht: Could we have an example of such a page?
bht@actrix.gen.nz 2001-09-29 19:21:54 PST
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.
Jason Kersey kerz@mozillazine.org 2001-09-29 19:44:20 PST
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.
bht@actrix.gen.nz 2001-09-29 20:22:05 PST
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.
Jesse Ruderman jruderman@gmail.com 2001-09-29 21:02:25 PST
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.
Hixie (not reading bugmail) ian@hixie.ch 2001-10-03 09:23:43 PST
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.
Copyright 2001