I think I've come up with a pretty good solution to one of the problems I noted with the menu script. I've found a way to avoid overlap of the menu with items above it.
First, inside the HTML I've created a wrapper div around the menu and content (note: I could probably just place the wrapper around the menu itself). The wrapper is relatively positioned at 0/0. Since this item will automatically fall below the header content it provides a "safe" area in which to scroll the menu.
Second, the CSS was adjusted to take into account that an absolutely positioned node is positioned relative to any parent node that is also positioned. Since the top of the wrapper div also indicates the top of the content area I specify an absolute positioning of 10 from the top.
Third, the JS uses a script from QuirksMode to calculate the position of the menu relative to the document rather than the wrapper div. This allows me to specify a fixed position that is below the header with Mozilla, thus avoiding overlap with that browser. With IE I determine the position of the menu relative to the wrapper div (taking into account the starting position of the menu relative to the document). I was going to just use the same procedure for IE and Mozilla in the script, but it turns out Mozilla has buggy support for the onScroll event.
I've ignored two other possibile problems for now: the menu extending beyond the lower bound of the browser window, and the menu overlapping the footer.
It's always the bit player ...
Among some of the other problems I'm experiencing with Safari, I'm having a problem with the menu script. For some reason Safari does not display the scrolling menu correctly after the initialization script is run. A visual inspection of the values at the end of the init script (using an
alert statement) gives the expected answer. However, the menu is positioned on some pages as if the new top value has not been set; Safari appears to be using the original value set in the CSS files instead of the javascript-defined value for display. This behavior, unfortunately, is not consistent throughout the site. On top of the inconsistency, Safari only seems to have this problem if the positioning is set to fixed at the same time as the value for the top style is set. Perhaps all those conditions will lead me to a clue regarding the source of the problem. I'll have to investigate further tomorrow.
Update 2005-01-14: I seem to have solved the menu problem in Safari. Unfortunately, it requires a bit of a hack because Safari appears to have bug when using javascript to set the positioning style of an object to
fixed while modifying the left/top parameters at the same time. The bug only rears it's head in a very specific circumstance and does not appear to be consistent (but is at the very least highly likely).
The layout: HTML document containing nested
divs. The outer div is positioned relatively at 0/0 (allowing the inner div to have an absolutle position that is relative to the outer one). The inner div is positioned absolutely at the desired starting point.
The procedure: The style of the inner
div is modified after the page loads to fixed positioning. Since fixed positioning is relative to the viewport (the browser window in this case) the visual position of the div will change. To avoid this we determine the position of the div relative to the document and reset the left/top information (well, just the top in the case of the menu).
The above procedure is used with browsers that are DOM- and CSS2-compliant. No problems are encountered with Mozilla. Safari, however, ignores the adjusted left/top settings if the positioning style is set to fixed at the same time. This can be avoided by setting the positioning style after a delay (using
setTimeout).
One more step is required, however. Safari correctly positions the menu, but leaves a ghost of the menu in the previous position. The ghost disappears on scroll and so is some sort of display artifact. To work around this problem the menu display style is set to
none prior to adjusting the positioning style. The final step sets the display style to block. Safari appears to have no further problems with the menu.
I'm going to submit a bug report to Apple, and perhaps post this on a newsgroup as well.
Update 2005-01-14: It appears that the bug requires an even larger confluence of events than originally imagined. I had only been adjusting the top value and not the left one as well. This appears to be the true source of the problem. If both left and top values are set then there are no problems with Safari (and thus no work-around needed).
I may still report this to Apple, but it seems less of an issue now than before.
