reptile7's JavaScript blog is Andrew Peak's personal technical writing project: it focuses on JavaScript and the analysis of JavaScript scripts, although HTML, CSS, and anything else related to coding for the Web are also fair game.

When the lightbox.html page for the user has finished loading, the lightbox.js script's initLightbox( ) function is called per its assignment to window.onload by the script's addLoadEvent( ) function as discussed in the Pre-load section of the previous post. The initLightbox( ) function does two things:
(1) It registers the script's showLightbox( ) function with the rel="lightbox" anchor elements in the lightbox.html document.
(2) It codes, but does not display, most of the lightbox image viewer.

showLightbox( ) registration

The lightbox.js showLightbox( ) function, which does display the lightbox image viewer and which we'll get to later, is registered with the rel="lightbox" links by the following code:

We first check the browser's document.getElementsByTagName( ) support; browsers without that support are sent packing, i.e., they exit the initLightbox( ) function via a return statement. The getElementsByTagName( ) method goes back to Level 1 of the Core DOM, so unless you're using a really old browser (as in IE 4.x/Netscape 4.x or earlier) you should be good to go.

We next scoop up all of the lightbox.html anchor elements, whether or not they are associated with the lightbox image viewer; these elements are organized as an anchors array.

We wouldn't need to screen for the href attribute if we were to instead work with the document.links[ ] collection. Moreover, the lightbox links are more appropriately grouped via the class attribute than via the rel attribute. If we give each lightbox link a class="lightboxLink" marker, then the above showLightbox( ) registration code can be rewritten as:

I really do appreciate this wonderful image viewer script but then I would like my user to just hover over the image to produce a lightbox effect showing a larger image rather than clicking on it first. How can this be done?

Just replace onclick with onmouseover and you've got it, Tobe.

Viewer structure

The remainder of the initLightbox( ) function codes almost all of the lightbox image viewer's structure, most of its behavior, and some of its functional (layout-related) styles. Assuming that the loading.gif and close.gif images are available, here's the structure that we'll be creating:

The lightbox div holds the close.gif image, an img placeholder for the main image (whose src will be set later), a div container for an image caption (currently empty), and a div containing a press <kbd>x</kbd> to close 'keyboard message'; variabilized as objLightbox by its createElement( ) command, it is added to the body element as a sibling of the overlay div by:

Before moving on...
The W3C doesn't have much to say about the kbd element: Indicates text to be entered by the user - that's all that's there, folks.

Viewer behavior

The lightbox.js hideLightbox( ) function, which zeroes out the lightbox image viewer and which we'll get to later, is registered with the overlay div (objOverlay), the overlay div's anchor element child (objLoadingImageLink), and the lightbox div's anchor element child (variabilized as objLink by its createElement( ) command), more specifically, a function ( ) { hideLightbox( ); return false; } function expression is assigned to the onclick attribute of these elements:

The objLoadingImageLink assignment is redundant: even if we were to click directly on the loading.gif image, that click event would bubble up to the overlay div. And because the only purpose of the objLoadingImageLink link is to serve as a carrier for a hideLightbox( ) trigger, it follows that the link itself is redundant and can be thrown out. For that matter, the objLink link is also unnecessary as its hideLightbox( ) trigger and title attribute can be transferred to the lightbox div.

If the hideLightbox( ) registrations are vested in the overlay and lightbox divs, then they can be simplified to:

The origin (upper-left-hand corner) of the overlay div is aligned with that of the document content area by the position: absolute; top: 0px; left: 0px; declaration set.

I initially suspected the overlay div's width: 100%; style to be unnecessary as the div element, like most block-level elements, ordinarily has an effective width of 100%: I was wrong. As an absolutely positioned, non-replaced element with a non-autoleft value and an autoright value, the overlay div actually has a "shrink-to-fit" width*; in practice, that width will shrink to 0 when the loading.gif image is later removed from the div's "box" by virtue of its own absolutepositioning that centers it in the viewport, or at least that's what happens on my computer, and so yes, we do need to give the overlay div a specific width.

*Regarding theshrink-to-fit width = min(max(preferred minimum width, available width), preferred width)
formula, the "available width" is the width of the div's containing block (i.e., the width of the viewport, see below) whereas the "preferred minimum width" and the "preferred width" are both evidently 0 if the div doesn't contain any renderable content, and thus it's the "preferred width" that establishes the width of the div.

These statements also appear in the showLightbox( ) function, which uses the arrayPageSize/arrayPageScroll returns to further lay out the overlay div, the loading.gif image, and the lightbox div; however, initLightbox( ) does nothing with the arrayPageSize/arrayPageScroll returns.)

There's no need to zero out the lightboxCaption div as its parent lightbox div is zeroed out.

The z-index stuff deserves its own section and we'll go through it next time.