I've run into this frustration before with IE-Win not properly stacking absolute and relative positioned content. See a screen shot of IE-Win and Firefox side-by-side rendering the sub navigation DHTML menus (<!-- m --><a class="postlink" href="http://template-tk.ispi.net/vimages/L3/skin3/IE-Positioning-Bug.gif">http://template-tk.ispi.net/vimages/L3/ ... ng-Bug.gif</a><!-- m -->).
Live link: <!-- m --><a class="postlink" href="http://template-tk.ispi.net/?template=L3">http://template-tk.ispi.net/?template=L3</a><!-- m -->
Related files
* <!-- m --><a class="postlink" href="http://template-tk.ispi.net/css/L3/skin3/screen/layout.css">http://template-tk.ispi.net/css/L3/skin ... layout.css</a><!-- m -->
* <!-- m --><a class="postlink" href="http://template-tk.ispi.net/css/L3/skin3/screen/DHTMLmenu.css">http://template-tk.ispi.net/css/L3/skin ... MLmenu.css</a><!-- m --> (alternate style sheet enabled by JavaScript)
* <!-- m --><a class="postlink" href="http://template-tk.ispi.net/javascripts/dropdowns.js">http://template-tk.ispi.net/javascripts/dropdowns.js</a><!-- m -->
The main navigation is a series of unordered lists where <li> tags contain another unordered list that's absolutely positioned. The general markup structure of the main navigation is below:
<ul id="navRoot">
<li id="frontPageLink"><a>Front Page</a>
<li class="hasSubs">
<a>Parent section</a>
<ul class="subs" id="subs[n]">
<li><a><span>Parent section: </span>Sub section</a></li>
</ul>
</li>
<li><a>Parent section</a></li>
.
.
.
</ul>
<script>
initializeMenu(); // Call to function in dropdowns.js
</script>
1. The first-level <li> tags are floated left and not positioned.
2. The first-level <li class="hasSubs"> tags are positioned relatively, in addition to Number 1 above.
2. The first-level <a> tags are block level
With JavaScript enabled:
3. The second level <ul class="subs"> tags are positioned absolutely and given a z-index of 100; They are positioned down 100% and left 0. A negative .2em top margin pulls the sub menu up a little.
In IE-Win, using Holy Hack
4. The second-level <li> tags (inside <ul class="subs">) are floated left, given a 1 pixel height and 120px width to get rid of IE-Win's <li> + block level <a> tag bug.
Since the main navigation is written dynamically, i.e. the number of parent and sub sections will never be known, nor will their IDs, is there any sort of CSS hack to get IE-Win to properly stack relatively and absolutely positioned content without assigning each positioned element a unique z-index?How about visibility:hidden; on those links that stick through when the drop out menu is triggered?I can't do that because the number of links and their locations will vary with each drop down menu, and on an issue-to-issue basis at the newspaper. Besides, everything has to remain visible.
Nice idea though. I'm probably going to assign all the links z-indexes using javascript for IE-Win.Found a JavaScript fix for it. I just set the z-index of the first level LI tags to 1. I did so in the DHTMLmenu.css file, but IE-Win didn't recognize it, so I had to chop and hack my way through the DOM *grins deviously and pets an evil-looking dog*
Using a JS workaround was OK here because the styles for the DHTML menu were activated by JavaScript. I'm happy now. IE is ignorantly happy as usual.
Live link: <!-- m --><a class="postlink" href="http://template-tk.ispi.net/?template=L3">http://template-tk.ispi.net/?template=L3</a><!-- m -->
Related files
* <!-- m --><a class="postlink" href="http://template-tk.ispi.net/css/L3/skin3/screen/layout.css">http://template-tk.ispi.net/css/L3/skin ... layout.css</a><!-- m -->
* <!-- m --><a class="postlink" href="http://template-tk.ispi.net/css/L3/skin3/screen/DHTMLmenu.css">http://template-tk.ispi.net/css/L3/skin ... MLmenu.css</a><!-- m --> (alternate style sheet enabled by JavaScript)
* <!-- m --><a class="postlink" href="http://template-tk.ispi.net/javascripts/dropdowns.js">http://template-tk.ispi.net/javascripts/dropdowns.js</a><!-- m -->
The main navigation is a series of unordered lists where <li> tags contain another unordered list that's absolutely positioned. The general markup structure of the main navigation is below:
<ul id="navRoot">
<li id="frontPageLink"><a>Front Page</a>
<li class="hasSubs">
<a>Parent section</a>
<ul class="subs" id="subs[n]">
<li><a><span>Parent section: </span>Sub section</a></li>
</ul>
</li>
<li><a>Parent section</a></li>
.
.
.
</ul>
<script>
initializeMenu(); // Call to function in dropdowns.js
</script>
1. The first-level <li> tags are floated left and not positioned.
2. The first-level <li class="hasSubs"> tags are positioned relatively, in addition to Number 1 above.
2. The first-level <a> tags are block level
With JavaScript enabled:
3. The second level <ul class="subs"> tags are positioned absolutely and given a z-index of 100; They are positioned down 100% and left 0. A negative .2em top margin pulls the sub menu up a little.
In IE-Win, using Holy Hack
4. The second-level <li> tags (inside <ul class="subs">) are floated left, given a 1 pixel height and 120px width to get rid of IE-Win's <li> + block level <a> tag bug.
Since the main navigation is written dynamically, i.e. the number of parent and sub sections will never be known, nor will their IDs, is there any sort of CSS hack to get IE-Win to properly stack relatively and absolutely positioned content without assigning each positioned element a unique z-index?How about visibility:hidden; on those links that stick through when the drop out menu is triggered?I can't do that because the number of links and their locations will vary with each drop down menu, and on an issue-to-issue basis at the newspaper. Besides, everything has to remain visible.
Nice idea though. I'm probably going to assign all the links z-indexes using javascript for IE-Win.Found a JavaScript fix for it. I just set the z-index of the first level LI tags to 1. I did so in the DHTMLmenu.css file, but IE-Win didn't recognize it, so I had to chop and hack my way through the DOM *grins deviously and pets an evil-looking dog*
Using a JS workaround was OK here because the styles for the DHTML menu were activated by JavaScript. I'm happy now. IE is ignorantly happy as usual.