spacer

Webref WebRef   Sitemap · Experts · Tools · Services · Newsletters · About i.com

home / experts / dhtml / diner / resize
DHTML Diner Logo

This is a Netscape Navigator 4 technique. The in-page examples will only work in Navigator 4 versions with the bug (ex. v4.04).

Developer News
OpenOffice 3.2 Lands Amid Critical Changes
Red Hat, IBM Firmly in KVM Virtualization Camp
Red Hat Talks Up Open Source Cloud Plans

Ensuring DHTML Layout on Resize

This article has been completely revised.
The script works around a bug present in Navigator 4, the true nature of which was not correctly identified in the older version of the article.

The dreaded RESIZE problem is a cousin, if not an obnoxious younger brother, of the older, well-documented, "document.write" problem. That is:
Pages with dynamic content lose the dynamic content layout, when the browser window is resized.

Ensuring DHTML Layout: in theory

A layout created with DHTML can only be restored by reloading the page. In theory, therefore, we should capture the resize event and direct a script to reload the page. The users may have to wait, but at least they will not lose the intended page layout and any scripted techniques embedded therein.

We can accomplish the event handling in several ways. The two most elegant are:

<SCRIPT LANGUAGE="JavaScript1.2">

    function reDo(){ window.location.reload() }
    window.onresize = reDo;

</SCRIPT>
and:
<BODY onResize="window.location.reload()">

Ensuring DHTML Layout: in practice

Navigator 4 introduced the undocumented resize bug.

In the previous version of this article, we described the bug in this way:

Every page load seems to be interpreted as a page resize as well. If we resize the browser window displaying a page with the above script, the page will be reloaded every time it loads, causing endless looping. True, there are certain cases where the bug doesn't kick in, but it always does if there is a defined onload handler, as well as an onresize handler.

It seems we were victims of the "correlation vs. causation" fallacy. The resize event seemed to be related to the load event, because it would fire at the same time. In reality, the resize is not caused by the load event. It is caused by the appearance or removal of scrollbars:

Whenever a scrollbar is sized, the resize event is fired. Scrollbars are sized when the page loads, so the load/resize event occur together. If no scrollbars exist, the resize event is not fired. This explains the "certain cases where the bug doesn't kick in."

The resize event is, of course, fired correctly as well, when the browser window is resized by the user.

On the next page, we will demonstrate the bug and the conditions under which it occurs.



Produced by Peter Belesis and


The Network for Technology Professionals

Search:

About Internet.com

Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers

webref The latest from WebReference.com Browse >
Search Engine Optimization: Selecting and Embedding Keywords · Are Google's Language Translation Web Services Ready for Prime Time? · Installing and Using Meeplace, the Business Review CMS
Sitemap · Experts · Tools · Services · Email a Colleague · Contact FREE Newsletters 
 The latest from internet.com
UC Gaining a Foothold in Government · Workers Say Telework Is More Productive, Bosses Not So Sure · Kingston Debuts Power-Saving Memory Upgrades

All Rights Reserved. Legal Notices.
Created: May 07, 1998
Revised: July 28, 1999

URL: http://www.webreference.com/dhtml/diner/resize/