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.

Per the "Getting the script to work with MSIE" section of Blog Entry #109, let's say that we
(a) subtract the </a characters from the document.write( ) command holding the eHide( ) function call, and
(b) replace the eShow( )/eHide( ) document.all(name) references with document.getElementById(name) references.The Script Tips #92-93 Script should then work OK with Netscape 6+, right? But this is what I get with Netscape 7.02 on my computer when I mouseover, for example, the Word, WordPerfect, TPU, EEL, SNOBOL, Postscript text in the right-hand cell of the eighth row of the initial display table:

Pretty ugly, huh? Here are the problems that arise:

(1) Recalling that the div2 div parent of each pop-up table has a width value of 350px, the CSS background-color and border-style properties for the part of the pop-up table that 'overflows' (extends beyond the right edge of) the div2 div are set to their 'initial' values: transparent and none, respectively; in practice, the overflowing table portion appears to have a white background (the body element's background color shows through) and its border disappears.

(2) When the pop-up table pops up, the initial display table shifts downward - note in the above image that the top edge of the initial display table has been pushed below the top edge of the pop-up table (go here to see the correct table positions) - as though Netscape has added an empty line box to either the div1 or div2 div.

Why do MSIE and Netscape overflow the pop-up tables differently? The answer seems to lie with the pop-up table width.

What determines the width of an HTML table? The table element has an undeprecated width attribute with an #IMPLIED default value designation; #IMPLIED means 'optional' in a practical sense. The pop-up tables are not given a width attribute; for this situation, the HTML 4.01 Specification only says, In the absence of any width specification, table width is determined by the user agent. Not very satisfying, is it?

The CSS table-layout property is not set for the pop-up tables and thus takes its initial value of auto; consequently, the pop-up tables should be laid out according to the "automatic table layout" algorithm; at the same time, the W3C says, UAs [user agents] are not required to implement this algorithm to determine the table layout in the case that table-layout is auto; they can use any other algorithm even if it results in different behavior.

The following Section 17.5.2 paragraph is applicable to the pop-up table width:

If the table or inline-table element has width: auto, the table width used for layout is the greater of the table's containing block width and MIN. However, if the maximum width required by the columns plus cell spacing or borders (MAX) is less than that of the containing block, use MAX.

(3) As noted two entries ago, the containing blocks for the pop-up tables are established by the tables' absolutely positioned div2 div element parents, whose CSS width is specifically set to 350px.
(Interesting side note: somewhat surprisingly, the HTML div element does not have a width attribute.)

(4) MIN means the minimum width required by all the columns plus cell spacing or borders; complementarily, MAX, defined above, is the maximum width required by the columns plus cell spacing or borders. In determining the width of a table, the browser should lay out
(a) a MIN table by trying all possible line breaks in flowing the table's td/th content, and
(b) a MAX table by formatting the content without breaking lines other than where explicit line breaks occur.
(Some tables will not have different MIN and MAX forms.)
For example, the

The MAX widths of the pop-up tables vary, and the pop-up table with the largest MAX width is in fact (by virtue of the QA Partner (4Test) cell) the Testing table, whose MAX width is approximately 335 pixels, which is smaller than the div2 div width. Consequently, Section 17.5.2 would recommend that all of the pop-up tables be given MAX widths, and MSIE 5.1.6 does just that on my computer, as does Netscape 7.02 iftable is assigned to the tables' display property in the eShow( ) function.

With a display = "inline" or display = "block" eShow( ) assignment, however, Netscape 7.02 does not use MAX widths for the pop-up tables; rather, in these cases Netscape seems to follow the third rule of Section 10.3.7 (width = right = auto; left ≠ auto) and give the tables "shrink-to-fit" widths according to the following formula:

Section 10.3.7's "preferred minimum width" corresponds to Section 17.5.2's MIN width; its "preferred width" corresponds to the MAX width. The "available width" is obtained by solving the following equation for width after right is set to 0:

For all ten pop-up tables, the preferred minimum width is greater than the available width. The pop-up tables with the smallest preferred minimum width are the Assembly and Statistical tables; for both of these tables, the preferred minimum width is approximately 195 pixels:

The Assembly pop-up table with a preferred minimum width - as in the image at the outset of this post, note the line breaks between "Years" and "Used" and between "Last" and "Used".

By definition, the preferred minimum width can never be greater than the preferred width (for some tables, these widths will be equal), and for all ten pop-up tables, the preferred minimum width is less than the preferred width. It follows that Section 10.3.7 would recommend that all of the pop-up tables be given preferred minimum (MIN) widths, and that's what I see with Netscape 7.02 on my computer.

For the shrink-to-fit width to equal the preferred width, it is necessary for the pop-up tables' available widths to be greater than both their preferred minimum widths and their preferred widths, i.e.,
(a) max(preferred minimum width, available width) must give the available width, and
(b) min(available width, preferred width) must give the preferred width.
As noted above, the pop-up table with the largest preferred width is the Testing table. In turn, for the pop-up tables' available widths to be greater than the Testing table's preferred width (335 pixels), it is necessary for the width of the tables' containing blocks to be at least 204 pixels larger than the Testing table's preferred width (cf. the available width formula above). And indeed, I find that increasing the div2 div width value to 545px (or higher) successfully imparts preferred (MAX) widths to all of the pop-up tables (all th/td line breaks are removed) and sorts out their overflow problems when using Netscape. Alternatively (and preferably IMO), the div2 divs can be removed, and the div1 div, with its effective width value of 100%, can be used to establish the containing block for the pop-up tables.I find that the downward shift problem is solvable via either
(a) bringing the initial display table into the div1 div (so that it's a sibling of the script element that writes the pop-up tables)

or (b) using the visibility property instead of the display property for hiding and showing the pop-up tables as described in the previous entry.
I admit that these are trial-and-error solutions and I don't have explanations for them.

Both solutions place the pop-up tables 5 pixels below their MSIE position (as though the tables were inheriting the 5pxtop value of their div2 div parents - the CSS top property is in fact not inherited); to the extent that this bothers you, the MSIE and Netscape positions can be harmonized by adding a top: 0px declaration to the pop-up table elements' style attribute.

In the next entry, we'll wrap up our discussion of the Script Tips #92-93 Script with a demo, a style sheet, and some final commentary.