In the first article in this series, I was forced to resort to Javascript code to match the central column heights that were too disparate to allow a single minimum height setting to cover all instances. Nonetheless, I used a simplification where on my site I knew the center column would outgrow the side columns. Hence, I could use simpler code. Now the footer columns in the menu template are not quite as well structured, however, the differences in heights are minimal in comparison to the range in the central columns. Therefore, setting the minimum heights in the cascading style sheet was the simplest most effective method to reach the goal for this site.
My solution is NOT perfect and it took some manual changes in the minimum height setting to get the best match. However, under certain conditions the menu page appearance is not optimal. I may be forced to change the order of subsequent postings to delay the promised Javascript fix for the footer. If that becomes necessary I will mention it in the introduction of the next article in this series.
Here is a repeat image shown in the first article where the longer midsection columns fit, but the footer columns at the bottom have mismatched heights:
Figure 1. Menu Short List Screen Shot (Enlarge) Matched Heights
Even I just looking at the footer div regions was unsure which was the larger. Hence, by sight alone I could not identify the major cause of the mismatched column heights. It was only after I diddled with the minimum height settings I saw the red, vertical border lines were associated with the central div. I invite you to view the mismatched heights above and in the graphics that follow. Please note there are relatively small differences between the three footer columns and their contents are unlikely to change radically. Therefore, changing selected columns to a new set of minimum heights was the quickest, easiest method to make the heights match.
While I am still uncertain why Javascript code seemed to affect an unrelated page template, I am taking the precaution of uniquely renaming the footer div tags. This serves two purposes, makes it less likely later code would be expressed in unexpected regions. The second is I probably will need these unique names to run the same Javascript function over differing areas of the same page. I began by copying the original footer div tags (in a test cascading style sheet):
/* [comments ...] */
#bottom-left {
position: relative;
float: left;
width: 21%; /* 20.90%; will not work with Safari */
height: auto;
background-color: #ADD8E6;
text-align: center;
font-size: 75%;
padding-right: 3px; /* was missing */
min-height: 150px;
}
/* central column in bottom header */
#bottom-central {
position: relative;
float: left;
width: 56%;
background-color: #FDFFFF;
color: #000000;
border-left-style: solid;
border-left-color: #b22222;
border-left-width: thick;
border-right-style: solid;
border-right-color: #b22222;
border-right-width: thick; /* 8px; */
text-align: center; /* just temporary presence */
min-height: 150px;
height: auto;
/* border-fit: auto; */
}
/* right column in bottom header */
#bottom-right {
position: relative;
top: auto;
float: left;
width: 21.5%; /* 22.37%; */
height: auto;
background-color: #ADD8E6;
color: #000000;
text-align: center;
font-size: 81%; /* 85%; */
min-height: 150px;
}
Before moving on to the new set of menu footer div tags, I think it is instructive to point out errors that have gone unnoticed (by me) despite obvious multiple reworkings of these entities. In the first div, note the third line for the width has been changed due to a browser incompatibility [1.] as noted in the comment. Nonetheless, look at the same line for the width for the bottom, right footer and see there the error persists. It just happens it is less visible. Therefore, I think it is a good idea to review old code with a fresh eye whenever possible, it just might hold clues why those odd appearance features come out of nowhere.
The first change was to add "menu-" to each id selector above:
#bottom-left {...} went to #menu-bottom-left {...}
There were no other changes. In the same manner I prefixed the names of the other two in the same fashion. Before examining the subsequent changes, here is a graphic that focuses on the footer region solely:
Figure 2. Menu Footer Screen Shot (Enlarge) Mismatched Heights
where the mismatched columns heights are clearly visible.
I only changed the minimum heights for two of the footer columns. This sufficed for my site, because the central footer column proved to be the larger. Thus, I needed to only only change those values on the two adjacent side columns.
Below I am showing only the lines of code changed in the test cascading style sheet:
/* footer columns just for menus */
/* left hand area in bottom menu header */
#menu-bottom-left {
...
min-height: 193px;
}
/* central column in bottom menu header */
#menu-bottom-central {
/* no change */
}
/* right column in bottom menu header */
#menu-bottom-right {
...
min-height: 193px;
}
These changes were implemented in the test menu template that I used to verify the effectiveness of my code changes. Here is the html and php code (with some comments removed):
<div id="bottom-header">
<div id="menu-bottom-left">
<?php
readfile($graphic . "/left-footer.txt");
?>
</div> <!-- end bottom-left-->
<div id="menu-bottom-central">
<?php
readfile($navigate . "/home-button.txt");
readfile($navigate . "/navigate-menu.txt");
?>
<h6>Last update January 02, 2009</h6>
</div> <!-- end bottom-central-->
<div id="menu-bottom-right">
<?php
readfile($graphic . "/firefox-3.txt");
?>
</div> <!-- end bottom-right-->
</div> <!-- Bottom header, with navigation and site data -->
Other than the div id changes, notice in the right hand div the file now sports a link and graphic to the newer version of Firefox. Put this together and in the last screen shots we see the columns are now well matched:
Figure 3. Menu Footer Screen Shot (Enlarge) Matched Heights
This column height match required fine tuning after an overshoot. Indeed, I needed to decrease the minimum height setting a single pixel at a time to get the best fit. Despite the effort the results were not perfect. A full screen view of my site even on my non-wide screen monitor is not fully pleasing to my eye. However, that problem will be dealt with in a later article.
If the column heights differences were of the order I have on my site and the content were as stable, I would use the cascading style sheet and simply adjust the minimum heights as shown. It is the most direct method and the easiest to effect. However, for completeness I intend to investigate how I would get a similar result using Javascript. Nonetheless, for me this is an excercise not a nescessity, hence, I might make the code a bit more general than would be needed for my site.
Despite my intentions to cover the same ground using Javascript, it may be necessary to revise the articles order. I might attack the page rendering problem where the browser uses the full screen. I have reason to believe this might be the easier problem, since I have partially tested this fix on another site. Nonetheless, even that article might be delayed while I clear a few items on my to do list. One would be a short note on internal bookmarks between pages and a brief article on using a networked printer where dynamic IP assignment rules. It depends upon which gives me the least resistance.
Corrections, suggested extension or comments write: H. Cohen.
© Herschel Cohen, All Rights Reserved
____________________________________________________________________
1. Simply escaped notice, though there were known problems at
right edge. Return
____________________________________________________________________