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.

We begin by noting that each pop-up table is given a Titles element identifier - id="General Programming" (Titles[0]) for the first table, id="Testing" (Titles[1]) for the second table, id="Windows" (Titles[2]) for the third table, and so on:

The eShow( ) and eHide( ) functions are respectively called by onmouseover and onmouseout commands carried by the anchor element parents of the font elements that hold the blue text of the right-hand cells of the initial display table (go here to see the initial display table):

We noted in the previous entry that the pop-up tables are respectively housed in separate parent div elements, to which we gave a class='div2' identifier. In his "Post the Tables" article, Joe incorrectly states three times that the eShow( )/eHide( ) functions act on a table's div element container. Actually, as shown by the above code,
(a) the div2 divs aren't 'hidden' in the first place, and
(b) the onmouseover/onmouseout commands send an id value (Titles[i]) for a table to eShow(name)/eHide(name), which then act directly on the table (document.all(name)) itself.

Contra the "Post the Tables" discussion of the pop-up process, it is not true that [t]he table is created each time the mouse passes over, not before; all ten pop-up tables are created before the user mouseovers any text (and before the script document has loaded, for that matter).

Moreover, Joe insinuates that the pop-up tables pop up when the user mouseovers the Titles headers in the left-hand cells of the initial display table when he says, Depending on which word is passed over, that value is passed to the [eShow( )/eHide functions] - also not true. But now that I think about it, I like the idea of shifting the onmouseover/onmouseout commands to the left-hand cells in some way, say, to a span element wrapper for the Titles headers.

The CSS display property of the pop-up tables is initially set to none; eShow( ) switches the table display value to inline whereas eHide( ) toggles it back to none. For showing the pop-up tables, a blockdisplay value would seem to be a more natural choice for the following reasons:
(1) The pop-up tables are absolutely positioned; according to Section 9.4.1 of the CSS 2.1 Specification, absolutely positioned elements...establish new block formatting contexts.
(2) In the absence of positioning, tables are typically rendered as block-level elements anyway.
(3) Perhaps most fundamentally, there's no point in having the pop-up tables "participate" in an "inline formatting context" because there's no other content in the div2 divs for flowing next to them.
In practice, I find that both inline and block are suitable values for the eShow( ) document.all(name).style.display assignment.

Regarding eShow( ) and eHide( ), Joe states that these functions set the [table] to either visible or hidden. When the mouse passes over, [it's] visible. My 'radar went off' when I read this; visible and hidden are values for the CSS visibility property*, not for the display property. But I subsequently thought, "Given that the pop-up tables are taken out of the 'normal flow' via their absolute positioning, does it really matter whether they take up space or not in their 'invisible' state? [A visibility: hidden element and a display: none element are both invisible; however, a visibility: hidden element occupies its normal (visible) area, like an empty placeholder, on the page, whereas a display: none element doesn't occupy any space on the page.] Could we use the visibility property here if we wanted to?" In the event, I find that the tables' initial display: none declaration, the eShow( ) display = "inline" assignment, and the eHide( ) display = "none" assignment can be smoothly replaced by visibility: hidden, visibility = "visible", and visibility = "hidden", respectively.

(*FYI: visible and hidden are also values for the CSS overflow property. We'll discuss the pop-up tables' overflow of their div2 containing blocks in the next post.)

Finally, the quote formatting of the onmouseover/onmouseout commands deserves some comment. The onmouseover/onmouseout commands appear in document.write( ) parameters that are delimited with double quotes; consequently, the script's author has delimited the eShow( )/eHide( ) function calls with \"escaped double quotes - I myself would have used single quotes for this purpose, but to each his own. The eShow( )/eHide( ) arguments, Titles[i], are also quoted, specifically, they are surrounded (indirectly) by &quot;character entity references that also represent double quotes.

You wouldn't think (or at least I wouldn't think) that it'd be necessary to quote the Titles[i] arguments; the Titles elements should be perceived as strings by the browser. Indeed, if a

command is inserted after the document.write( ) commands carrying the anchor element start-tag(s), then ten alert( ) boxes all displaying string dutifully pop up. However, my attempts to pop up the pop-up tables after subtracting the &quot; references were unsuccessful; in this regard, here's what happens when I mouseover, for example, the MS-DOS, NDOS, DCL, JCL, UNIX text in the right-hand cell of the last row of the initial display table:

(A) MSIE 5.1.6 does not send Titles[9], Command, to eShow( ) but inexplicably sends instead a reference to the pop-up table whose id value is Command:

(B) Netscape 7.02 simply throws a Command is not defined error, i.e., Netscape evaluates the Titles[9] expression but still perceives the return, Command, as a variable lacking a value.

In sum, the &quot; references do need to be there (other quote formattings for the eShow( )/eHide( ) function calls are possible, but we're not going to get into them here). Alternatively, I find that both MSIE and Netscape will uneventfully pass an unquoted Titlesindex