Sunday, May 18, 2008
The Script Tips #92-93 Script, Part 5
Blog Entry #113
Getting the script to work with Netscape
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
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?
Fortunately, Section 17.5.2 of the CSS 2.1 Specification discusses table width in some detail. The pop-up tables are "absolutely positioned, non-replaced elements", whose widths are generally determined by rules given in Section 10.3.7 of the CSS 2.1 Specification; Section 17.5.2 is supposed to "override" the Sections 10.3.x pertaining to non-replaced elements, however.
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.Let's flesh this out one step at a time.
(1) In the previous entry, I argued that the script's eShow( ) function should set a pop-up table's display value to block and not inline. I neglected to point out that the CSS display property has specialized table and inline-table values for flowing tables in a block-level and inline manner, respectively; relatedly, the table element is given a display: table style in the CSS 2.1 Specification's "Default style sheet for HTML 4" appendix. Recasting the eShow( ) function as
function eShow(name) { document.getElementById(name).style.display = "table"; }
solves the pop-up tables' background-color/border-style overflow problems but does not solve the 'downward shift' problem when using Netscape.
(2) The CSS width property is not set for the pop-up tables and thus takes its initial value of auto.
(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 breaksin 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
<td><b>QA Partner (4Test)</b></td>
cell in the Testing pop-up table would be flowed as
| QA Partner (4Test) |
in a MIN table and as
| QA Partner (4Test) |
in a MAX table.
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 if table 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:
left + margin-left + border-left-width + padding-left + width + padding-right + border-right-width + margin-right + right + scrollbar width = width of containing block
• left, set by the pop-up table elements' inline style attribute, is 200px.
• margin-left, margin-right, padding-left, and padding-right all take their initial values of 0.
• border-left-width and border-right-width, set by the pop-up table elements' border attribute, are both 2px.
• The pop-up tables do not have right scrollbars and thus the scrollbar width is 0; as noted above, right (initially auto) is 0 and the width of the containing block is 350px.
Plugging in the above values and solving for width gives an available width of 146px. Now, let's turn to the inner part of the shrink-to-fit width expression:
max(preferred minimum width, available width)
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".The outer part of the shrink-to-fit width expression then becomes:
min(preferred minimum width, preferred width)
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)
<div id="div1" style="position:relative;">
<script type="text/javascript"> ...pop-up table code... </script>
<table border="0" cellspacing="4"> ...initial display table code... </table>
</div>
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 5px top 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.
reptile7
- posted by A. Peak @ 3:00 PM
Actually, reptile7's JavaScript blog is powered by Café La Llave. ;-)