Web Site
Developers
Web Page Appearance and Javascript
Reasons for Inaction
I recognized I was mistaken when I thought my multiple, parallel div columns matched heights. I knew too well it was the background color of my base div hid the failure as the columns changed heights. However, it was more than simple inertia delayed efforts my correcting this too visible flaw in the menu pages. A myriad of other perplexing issues monopolized my attention. Moreover, I thought I had simple solutions stored on my system utilizing seemingly very straight forward javascript code. Furthermore, the problem of matching column heights seemed to be a well understood problem with its solution documented. Or so I thought, until my browser crashed losing all the code samples, irretrievably. I soon learned the solution was not so simple. I ended up developing my own code. Oh yes, welcome to the strange world of Javascript.
Where the Non-Matching Column Heights Became Visible
When I wrote [1.] that the div columns matched, I unknowingly had what is called a faux [2.] fix. Due to my choice of column colors initially and having nearly the same shade on the base div hid the mis-match. When I began to use a different background colors in the left and right columns in my set of menus, even there is was not immediately obvious I had an issue. However, as some menus grew in size it became clear the central column content caused an increasing disparity in heights.
Here is a screen shot of a menu that fits without problem:
Figure 1. Menu Short List Screen Shot (Enlarge) Matched Heights
And here is another, which exhibits the mis-match when the menu content grows beyond the size of the preset minimum height in the cascading style sheet:
Figure 2. Menu Long List Screen Shot (Enlarge) Unmatched Heights
While there is an obvious mis-match of columns in the footer area, that problem will be attended to in a later discussion. For now the focus is solely upon the longer of the three central columns. I advise looking at the dynamic menu first before thinking the simple fix of choosing a longer fixed pixel minimum height could solve this site's menu display problems. The minimum height necessary would be too extreme to be justified. Where possible, yes, opt for the simpler solution, but here we have little choice. Nonetheless, I will use simpler conditions where less complex code is allowed. Now let's move on to possible means of attack.
First My Dislike of Javascript
I think it is best to admit immediately to my being biased against Javascript. Moreover, recent experience has not altered my view. My predisposition to distrust Javascript was built upon reading and hearing how it was the means used to compromise Firefox. Therefore, I disallow Java/Javascript use by default for nearly all web sites I visit.
I have dropped the rant against Javascript that was in this location for a more constructive article later. In that article, I plan to discuss how I see Google searches being coopted to use inferior results [3.]. As you will see below, I wrote my own Javascript code that is functional. However, I lack confidence in it, precisely because it works too well. That is, I see evidence of its effectiveness upon pages where it does not reside [4.], but not under all conditions [5.].
I have other reasons for being dubious of Javascript, since I have seen code functional failures without seeing any message of any cause. The suggestion I was given was to try a different browser or if I developed in dot Net the built-in debugger where the defect might be caught. I found both to be unacceptable. Thus, I struck out on my own. Let this suffice, it is time to examine a working solution.
Javascript Code that Worked
Working Code
In the header section, a fairly simple function that accomplished the task of matching the left and right columns to the central columns' menu listings [note "\" break lines to fit within allotted space]:
<script language="JavaScript" type="text/javascript">
function matchHeight() {
if (typeof document.getElementById \
!= 'undefined' && document.getElementById("central-col-bst") \
!= null || document.body != null) {
alert("Web page is ready, getElementById \
is there and the body painted.");
var leftDiv, rightDiv, maxHeight,divHeight,div_central, cent_col;
div_central = document.getElementById("central-col-bst").offsetHeight;
alert("div_central clientHeight run and its height is: " + div_central + "px");
maxHeight=650; //true for the menus
alert("Maximum column height set to: " + maxHeight);
if (div_central < 651) {
// do nothing
alert("Do nothing, sees standard min height. Div height is " + div_central);
maxHeight=650; //true for the menus
alert("Maximum column height set to: " + maxHeight);
if (div_central < 651) {
// do nothing
alert("Do nothing, sees standard min height. Div height is " + div_central);
} else {
maxHeight=div_central;
alert("New maxHeight is: " + maxHeight);
document.getElementById('col-left-bst').style.height =maxHeight +"px";
document.getElementById('col-right-bst').style.height=maxHeight +"px";
alert("left, right cols. set to: " \
+ document.getElementById('col-left-bst').style.height \
+ ", " + document.getElementById('col-right-bst').style.height \
+ " respectively");
}
} else {
// this is strickly error trapping to
// be assured the code did not execute
// too soon.
alert ("In second if portion of code");
}
}
</script>
One small piece of code is required to be assured, the above code runs after the loading of the web page. It is necessary to add the onload command withing the starting body tag:
<body onload="matchHeight()">
Satisfactory Result?
In a word No. While I will keep this probably unaltered, albeit moved outside the page, its [the javascript code] has unexpected effects where it is not visibly present is disconcerting. However, let us not overly obsess about my qualms, let's look at the result.
Figure 3. Menu Long List Screen Shot Unmatched Heights Aligned with Javascript
This time there is no enlargement, because you can run the code to see the steps using a testing code link a bit below. For now it is just obvious Javascript code listed above works.
Javascript Code in Action
Production Implementation Delay
Until all the code in these templates is modularized [6.], use this the modified home page's left column to access [7.] Javacode activated menu template. I advise just walking you through the code [8.] and accepting the intermediate messages. Finally, please pay attention to footnotes in this section.
Matched Central Column Heights Example
If you use the link above, you may see suddenly that the home page suddenly has been altered. That is what I see [sometimes] on a Linux box running Firefox. If, in contrast all seems fine, well I saw that to using another OS and Firefox. Just one more reason for my skepticism of Javascript's stability or my coding skills. Eventually, these changes will not require the multiple alert functions, which represents a significant fraction of the total Javascript code. In contrast the code examples I found were much more complex or used large external libraries.
Conclusions
Javascrpt Utility
My experience confirms, when you have a complex set of criteria to match in real time on a client's browser Javascript seems to be a valid choice when no palliative can meet the requirements. Supposedly asynchronous web sites depend upon its, Javascript, properties, however, I lack the experience to comment upon how well it fulfills the role. Nonetheless, should I be involved in such a project a priori, I would put some effort in seeking an alternative.
Avoid Javascrpt
At present, I have a rule for Javascript, i.e. avoid it at every opportunity. Yes I am being flippant, however, my experience to date leaves me dubious. Nonetheless, I do not discount the possibility that the fault may lie in my lack of skills. Therefore, I would not eliminate Javascript from consideration.
I have seen better code than I have been able to find recently. I attribute this now to a skewed search results problem. Hence, do not expect me to forever follow the above rule.
Corrections, suggested extension or comments write: H. Cohen.
© Herschel Cohen, All Rights Reserved
Return B/ST Home or Problems Page
____________________________________________________________________
1. Seemingly eons ago, Summer or Fall of 2007 originally on
the defunct OpenSourceToday site. Return
2. The type I mentioned, i.e. a common backgroud color
hiding the differing heights of the column panels.
Return
3. The listings seemed almost incestuously interlinked
showing nearly the identical code. That alone would not
support my harsh stance. It is the code seems at least
partially depreciated that fuels my skepticiam. Return
4. I see lenghtened columns where there should be no
supporting code. Return
5. However, using the Mac OS X and the same version of
Firefox, the main page and other areas behave as I expect.
Return
6. Look at the Dynamic menu listing of "Error Catching &
Page Templates" that has php code that sends emails from
multiple locations with differing messages. This
redundant code has to be modularized. Items two - five
should have examples of sending error messages from
diferent locations. Return
7. Only the list in the left column calls the new template,
however, on some systems it will make no difference.
Return
8. I hope this is temporary, but I have been diverted
other times. Return
____________________________________________________________________