TreeMenu - Complex disappearing problem

[R0bert Neville]

My web page has one unordered list that disappears in Firefox. The
unordered list in question has the class="dir". I double-checked the
source code and verified the markup's semantics. Everything looked
fine. So I placed the code in the W3C validator and it passed with no
errors. Then I placed a regular unordered list with no class before
the previous unordered list. Upon a reload, the new unordered list did
not render, yet the unordered list with the "dir" class appeared. The
whole situation was strange.

After reviewing web page with the DOM inspector, the disappearing list
had been assigned {display: none}. Apparently, my JavaScript for
TreeMenu functionality was the culprit. I attempted to debug the
JavaScript. Sadly, my JavaScript knowledge is elementary even though I
successfully implemented the approach from
http://www.bakketun.net/listmenu/. When my web page became more
convoluted, the JavaScript began faltering along its seams.

Here are my discoveries while debugging (using Venkman). The
elementHasClass() should match the "element.ClassName" with
"TreeMenu." If not, the function return false. Unfortunately, another
function passes the div element to the setMenu(); then the said
function assign the display attribute; block or none.

But I can not pinpoint where the code goes down the wrong path;
needless to say develop a solution.

Please review the site below and let me know if you have suggestions.
View source and search for class="dir"; the disappearing list has the
text "test." Problematic code JavaScript area may include the line
listed below. This posting was intended as a short description.
Further clarification will be gladly provided if someone shows
interest in a particular aspect. I have pages of notes on the
debugging process.


http://neville.f2o.org/Template_Sample.html

Line 93
function setMenu(menu, open)

Line 75
setMenu(menu.parentNode, open);

Line 26
elementHasClass( menus[ i ], "keepopen" )

Line 106 is the following:
initMenus();

 

[Thomas 'PointedEars' Lahn]

My web page has one unordered list that disappears in Firefox. The
unordered list in question has the class="dir". I double-checked the
source code and verified the markup's semantics. Everything looked
fine. So I placed the code in the W3C validator and it passed with no
errors.

| The Validator XML support has some limitations
| <http://openjade.sourceforge.net/doc/xml.htm>.

Then I placed a regular unordered list with no class before
the previous unordered list. Upon a reload, the new unordered list
did not render, yet the unordered list with the "dir" class
appeared. The whole situation was strange.

Since you are sending XHTML as text/html when it should be
application/xhtml+xml --

<http://www.hixie.ch/advocacy/xhtml>

-- you force Gecko's parser to do error correction since
it uses the HTML parser instead of the XML parser then.

IE 6, OTOH, since there is no stylesheet linked and it does
not really know how to handle XHTML, displays the document
element tree.

I recommend to refrain from using XHTML where possible, i.e. where
additional features provided by XML applications compared to HTML 4.01
Strict are not required. Where not possible, serve it with the proper
MIME type instead of relying on error correction. Bear in mind that
the latter makes it incompatible with current IE browsers.

[...]
Here are my discoveries while debugging (using Venkman). The
elementHasClass() should match the "element.ClassName" with
"TreeMenu."

You mean `element.className'. ECMAScript implementations are
case-sensitive.

If not, the function return false. Unfortunately, another
function passes the div element to the setMenu(); then the said
function assign the display attribute; block or none.

I am not sure if this is of help regarding your current problem,
but there are more valid values for `display' than just `block'
and `none'. CSS implicates that e.g. `td' elements have
display:table-cell and `tr' elements have display:table-row
initially which is why Gecko implements them this way while IE
does not.

But I can not pinpoint where the code goes down the wrong path;
needless to say develop a solution.
[...]

You should have mentioned that the methods you are referring to
are defined in a script file where the respective `script' element
has been commented out (javascript/javascript.js).


PointedEars