Here, we have divided the width of half of the element by the number of visits (function calls). This gives us the pixel increment by which to clip the left and the right edges of the element on each function call. We do the same for the height, and then call the function.

In function zero(), we clip the four sides by the appropriate pixel increments. If both the clip width and the clip height become 0 or less, the transition is complete, so we clear the repeated function calls with clearInterval() and restore the element to its original size and hide it with hideIt().

This code results in the second example in the left column. If you are using Navigator 4, try it. What is the difference from the first example? The box does not reduce in size equally on all sides, as it does in Explorer. This is due to Navigator rounding numbers to integers, to use as pixel increments.

Let's make up for this behavior, by embellishing the code to account for (almost) every pixel!

The Long-Winded Correct Way

First we get a temporary horizontal increment (incW) by dividing halfW by visits, as above. We then check to see if incW is greater than 1 pixel. If it is, we take the full integer part of it (left of the decimal point), and assign it to incrementW using parseInt(). If incW is less than 1, we assign 0 to incrementW.

Next, we obtain the non-integer part of incW (right of the decimal point), by subtracting the integer part (incrementW) from it (incW - incrementW). If we multiply this fraction result by the number of visits ((incW - incrementW) * visits), we get the total number of pixels that will be stray and lost if we continue our routine as in the "wrong way" above. This number is then rounded to the closest integer using the round() method of JavaScript's built-in Math object: (Math.round((incW - incrementW) * visits)). Finally, the result (xtraPixW), represents the total number of extra pixels that we will need to account for to have the transition end in a point in the center.

We perform the same calculations for the element height before calling the zero() function.

The major problem in developing zero() is the use of the extra pixels. xtrapixW and xtraPixH will always be less than the visits, by definition. We need a smoother transition closer to the end of the transition, when the element is smaller. The way to achieve this is:

Clip the element by the integer increments (incrementW/incrementH) every time zero() is called, as normal.

If the extra pixels are less than the visits, clip by one extra pixel every second time zero() is called. Track the extra pixels used and the visits to date.

Eventually, the extra pixels still-to-use will equal the visits-still-to-come. From then on, until the end of the transition, use one of the extra pixels per visit.

If we have extra pixels to account for ( if (xtraPixW > 0) ), we compare the extra pixels to the visit count. If the extra pixel count is less than or equal to the visits ( if (xtraPixW <= visits) ), we check the value of alternateW, the Boolean declared earlier. If alternateW is true, then we increment the left clip by one pixel ( this.clip.left++ ) and decrement the right clip by one pixel ( this.clip.right-- ). We then decrement the extra pixel counter ( xtraPixW-- ).

The value of alternateW is then toggled, regardless of whether it was originally true or false. This ensures that an extra pixel will be used every second visit, that is, when alternateW is true.

If the extra pixels are not less than the visits, then zero() clips the left and right sides by one, and decrements xtraPixW.