Hi,
I’ve tried implementing the horizontal dropdown navigation menu from Sitepoint’s the javascript anthology, however the dropdown menus do not appear in the correct place in IE8…
I’d be very grateful for your help - I’m stumped!
Thanks,
Michael
Kinda offtopic, but you’re not actually going to do the menu with JS for the live site, are you? People without scripts on can’t click on anything… the hrefs should be going to “backup pages” which list all the stuff available in the dropdown. Or just use CSS with a bit of helpful JS for keyboarding and a slight mouseoff delay (but even then, main item urls should take people somewhere as a backup).
But as an exercise, it should work… we could see if there are IE8 Javascript bugs on James’ site: http://jhop.me/ie8-bugs#dom
Thanks for the advice. Yeah, we’re definately going to make the navigation more user friednly in developing the new site. This is just a temporary fix.
Do you have any idea roughly what kind of error we might be looking at?
The navigation is working well with the other major browsers. I must admit - I copied and pasted the code from the books code archive, however it looks like the code works in the following manner:
The CSS file sets the position of the drop-down navigation menus to be far off the screen to the left. The javascript changes the position of a drop-down navigation menu to make it visible when its parent link element is hovered over.
The question is, why would this change in position be different for IE8?
Would be most grateful for your help
Mike
Is the problem IE8 or IE in general?
floater
The problem also exists in IE8’s compatibility mode, and I see that the dropdown script uses browser detection.
I’ll see what I can find out about this later on today.
Hi Floater,
Yes, it does just seem to be with IE8. The code in the book “Javascript anthology” predated IE8.
Would be really great to get a solution together to help everyone who uses that book. So, I’m looking for a really hot coder who knows how to fix this. Any takers?
Thanks,
Mike
The first dropdown seems okay, while each one to the right is progressively further away.
I would look first at the CSS double float margin bug that IE has.
Thanks very much - good thinking, however I think anything post IE6 doesn’t suffer from the double float margin bug?
In which case you can target specific IE versions using conditional comments.
<!--[if gte IE 6]>
<link src="stylesheet" type="text/css" src="css/fixIE6plus.css">
<![endif]-->
A really nice way to produce a good drop-down menu without the use of JS is to use something like what’s implemented here:
That method uses unordered lists and pure CSS to create a working menu that rquires no javascript, and degrades gracefully for those with ancient browsers (read: PRE-IE4 and NN4). I’ve never tried a screen reader on that page, but I suspect that it will work well.
Dave,
since my sound’s out on my virtual box I can’t actually test, however that menu does use display: none which, unfortunately, is still honoured by screen readers. Since screen reader users aren’t going to be :hovering over anything, they’ll never get the subs to appear. The reader agrees that their display state is “none” and therefore, they’re simply not onscreen and aren’t read out. So screen reader users (unless they have one that ignores display: none but the popular readers such as JAWS and Window-Eyes do not) are only going to get to your main-level links.
Pulling the subs offscreen with a ginormous negative margin or just left: -9999px keeps them “onscreen” as far as the reader is concerned, and so is a safer technique.
There are only some unique situations where display: none is ignored, such as labels in a form, but the other situations seem to differ per reader, and are basically bugs or quirks (like JAWS will read a span inside an anchor who is display none if the anchor has a background colour, weeeeeird) and can’t be relied upon.
Re this JS: while I wouldn’t use JS for a dropdown menu and agree with Dave, the point of the book is still to learn Javascript and while I had stopped with Simply Javascript after stripey tables, I intended to get back to it and would like to know an elegant solution to what’s up with IE8 (and if 7 really is affected) as well. I would hope there’s a way to do it without calling some other, separate script with IE Conditional Comments.
If it is the double margin float bug, placing display: inline on the floated elements should fix the bug.
As far as I know, that was limited to IE6. If it’s in IE8 (I don’t think I’ve noticed it in any pages I’ve written, but then again I might always have display: inline in there for IE6 by default anyway), then it’s a retro bug, as it is not present in IE7.
Silly us, instead guessing at the cause, books have errata pages.
It is a confirmed IE bug, and it is fixed with display: inline
Check the errata - they have updates for the code in the book.
http://www.sitepoint.com/books/jsant1/errata.php
Here’s the fix for the horizontal menu
/* 20080221: new hacks for IE7 */
*+html ul.horizontal li {
display: inline;
float: left;
background: #fff;
}
*+html ul.horizontal li { position: static; }
*+html ul.horizontal a { position: relative; }
The way they’ve done it may not be the best solution (it has code smells), but it is the solution that the book authors provide.
The “fix” is in the the example file (http://www.sitepoint.com/blogs/2009/04/01/the-right-way-to-make-a-dropdown-menu/) but doesn’t seem to actually “fix” the issue.
Because that “fix” isn’t for IE8.
*+html is an IE7 hack, NOT an IE8 hack. IE6, IE8 and modern browsers ignore anything comgin after *+html.
The display: inline, no clue why that’s there, it is IGNORED by IE7 on a float, just as with modern browsers. The real hack of the fix above is setting position to static.
And why they used two lines for the li for IE7, makes no sense to me. Position: static could be in the first statement with everything else.