[thelist] A variation on the NS4 resize bug

Gee gee at geedev.com
Thu Jan 25 17:02:31 CST 2001


I feel guilty to have lurked so long, only to surface with an esoteric,
stubbornly idiosyncratic problem. The fact that such happens all the time is
not much consololation. But anyway...

My issue pits PHP-generated dynamic text against the notorious Netscape 4
resize bug.

I have a static HTML page, into one layer of which I am pouring content
(text with some simple HTML formatting) taken from a MySQL database,
courtesy of PHP. You may wonder why I am pouring the text into a layer
rather than a table. A long answer is available upon request, the short
answer is that for sundry idiosyncratic reasons I want to avoid using tables
for layout or positioning.

Simple stuff, really. 'Cept for that NS4 resize bug (well, it's two bugs,
really, isn't it?)  Netscape 4 is determined to throw the layer positioning
out the window , leaving those ultra-thin, illegible columns familiar  to
CSS scripters everywhere. I know what you're thinking: use the venerable
Netscape Resize Fix script.

Get this, the script is already there. The bug doesn't happen upon resizing
the window, it happens upon loading the window. In other words, the first
time you load the page, the screen looks horrible. After you resize,
everything works fine. Makes for a rather inauspicious debut, and you know
how valuable first impressions are.

I submit to the jury the following exhibits:

http://geedev.com/evolt/zaid.php  The orignal problem file, with some
hand-tweaked scripting for liquid layout.

http://geedev.com/evolt/zeam.php Same idea, but with my customized script
replaced by Dreamweaver's ugly yet commonplace version of the Resize Fix.

http://geedev.com/evolt/zaidSOURCE.htm  View source to see the PHP
scripting.

The questions: What is going on? How can it be fixed?

Gee's Theory: I think the problem has to do with the way the fix to the NS4
Disintegrating Layer bug tries to routes around the NS4 Scroll Bar/Resize
bug. To wit, the procedure for a typical NS4 Resize Fix script is as
follows:

1. Get the width and height of the window upon loading of the page.

2. Tell the document (via functionA() ) to reload the page whenever it is
resized (because when the page is resized the layer positioning goes kaput.

3. Within functionA, check the width and height of the window (again),
compare to the original values, and continue only of the new values differ
from the original values, i.e., the window has actually changed size.

3a. In yet other words, tell functionA() not to continue if the "resize" is
mererly the addition of scroll bars or the loading of a page (both of which
Netscape 4 also interprets as a "resize"). If we didn't filter out those
instances, flavors of NS4x get caught in a reloading loop. ("If load/resize,
then load/resize, then load/resize, then load/resize...etc)

I think what is happening is that the static elements of the page, including
the resize fix scripting, is loading up and NS4 establishes the window
thinking all content fits inside. But then PHP adds the dynamic content,
which is more than will fit in the window, and NS4 throws in a scroll bar.
This counts as a resize in NS4 's head, so it throws out the CSS styles per
the bug. But since it is _not_ an actual resize of the window, the script
does not fire to correct it.

What does the jury think? If the theory is correct that mean the solution
lies within PHP? What would it be? I've tried toying with some of the
flush() and ob_start() ob_end_flush() settings, but I admit I'm a bit green
with PHP.

TIA for any aid or suggestions, and apologies for the length (when asking
for assistance, I like to make
giving the assistance as easy for the assistor as I can :-) )

BTW: I'm currently on the digest, but will promptly reply any questions sent
directly to gee at geedev.com, should more info be desired in a manner speedy.

Gee
||o






More information about the thelist mailing list