Firefox on Vista problem

[marjwyatt]

1) Script Title: All Levels Navigational Menu (v2.0)

2) Script URL (on DD): http://www.dynamicdrive.com/dynamici...menu/index.htm

3) Describe problem:

I suppose it is easy to blame it on Vista but I am having the queerest problem with this wonderful script. The script works perfectly in IE7 on Vista but, when I try it using Firefox 2.0.0.20 on Vista, I cannot get to the submenus without them disappearing. The same script running in Firefox 2.0.0.18 on XP works perfectly.

My Vista laptop is much speedier than my XP desktop and Firefox is a lighter browser so it could have something to do with the timing settings in the Java script but I am not a Java Script person and I'm not sure what to change. It behaves more like a cursor positioning error. I'm not even sure I'm stating this right.

Here is a link to the site, a work in progress (to be sure) but something that I've been struggling with for days. Interestingly, I've had to put more "hacks" in the HTML and stylesheet to get it to work properly in Firefox. Who says that IE is the only buggy browser anyway? (smile)

Anyway, back to the link:

http://doggietreasures.mildlymystifi..._vertical.html

Please help!

Marj Wyatt
Skype: marjwyatt
URL: http://www.marjwyatt.com

[jscheuer1]

I don't have Vista, but even if I did, I wouldn't be running FF 2 on it. The most recent version I'm aware of is 3.0.5. You should probably upgrade.

The only other thing that jumps out at me as a possible problem is the iframe shim of this script. It's for selects and Flash, however you appear to have neither, so I'd try disabling it:

 . . . onal "sliding" animation when sub menus are revealed.
	//2) Arrow images now dynamically positioned, instead of relying on CSS's "right" property

//** Oct 11th, 08'- Updated to v 1.5:
	//1) Sliding animation behavior tweaked
	//2) Added ability to disable iframeshim, customize speed of sliding animation

//** Dec 23rd, 08'- Updated to v 2.0:
	//1) Animation speed refined to be function of time (ie: 1 sec)
	//2) Added two animations that can be individually enabled/disabled- "slide in" and "fade in".
	//3) Script now automatically moves HTML for all sub menus to the end of the page, to avoid any containership issues if they are nested in other elements.

var ddlevelsmenu={

enableshim: false, //enable IFRAME shim to prevent drop down menus from being hidden below SELECT or FLASH elements? (tip: disable if not in use, for efficiency)
downarrowpointer: ["../vert_menu/ddlevelsfiles/arrow-down.gif", 11,7], //path to "down arrow" image that gets added to main menu items (last 2 parameters should be width/height of img)
rightarrowpointer: ["../vert_menu/ddlevelsfiles/arrow-right.gif", 12,12], //path to "right arrow" image that gets added to LI elements within drop down menu containing additional menus
hideinterval: 200, //delay in milliseconds befo . . .

One other possibility is your firewall/antivirus settings. There have been cases under vista where either the native applications for this or third party add ons have actually blocked some content, including some script code. However, I am not aware of any of the specifics of this, it's something you might want to investigate though, if upgrading FF and removing the iframe shim don't take care of the problem.

Just in general, about what you said in regards to hacks for FF. In most cases that means that you designed the page using IE to check the layout, then viewed it in FF afterwards. If you start with FF as your guide and then later view in IE, there will usually be less to correct, and since there are no good hacks (if that's what you really mean, they're all by definition tricks that rely upon browser quirks that may change), you may use the documented conditional comments available for IE to adjust style and content to tailor it to that browser's needs.

[marjwyatt]

Hi John,

Thanks for the tips. If you are the author of this code, I really do appreciate your sharing it. It is an elegant piece of work.

If it has something to do with firewalls and antivirus, that would be a big deal and I'd be forced to go back to the drawing board because it would be absurd to make demands of the global community to change their computing environment just to visit my client's website.

I will try disabling the Java Script feature you recommended and report back to the forum.

As for upgrading FF, I will hold off on that for a while. I upgraded to FF 3.0+ in late October and, when I encountered major problems and researched them on the web, I learned that many CSS developers were backing out the latest FF release. I followed suit. Vista wasn't really my first choice either but, when I got my new laptop, Sony would not deliver it with XP. Sigh...

My HTML editor emulates FF but I don't design pages for a specific browser. I'm not even sure why that would be a good practice. I write W3C complaint CSS which should transcend browsers and most times it does. I make sure to check the design in both browsers periodically to minimize disappointments and extraordinary efforts to chase down a glitch at the end of the project.

Firefox does have a known problem displaying background images. Since I tend to use a lot of them in my designs, I'm more sensitive to this. The truth is that I've had to add more code to facilitate viewing background images in in FF than IE over the past several months.

I subscribe to the belief that an application (such as a browser) is never the culprit. A patient developer will suss out the right combination of code to make things work smoothly for the end user.

Cheers!
Marj Wyatt

[jscheuer1]

I did not write this script. I'm not even familiar enough with its code to say for sure whether I like it or not.

If it is with the antivirus or firewall settings, these will be messing up scripts and other content for folks using FF 2 on a great many sites because they are simply too restrictive.

However, even if that is a contributing cause, upgrading the browser may still solve it. This sort of thing (dealing with new OS environments) is one of the reasons browsers get upgraded.

If you are writing valid code, generally there shouldn't be much of a problem in FF as far as layout and function goes. However, valid code doesn't necessarily guarantee code that works as intended in any browser.

Regardless, and this depends upon what you meant by 'hacks', these shouldn't be used. Code should be written for the more compliant browser and adjusted for IE using standard methods of IE conditional comments. If done in a thoughtful manner, this approach has the best chance of working in future versions of browsers.

[marjwyatt]

Hi John,

I don't disagree with anything you said and, if my HTML editor defaults to FF as the WYSIWIG viewer, I probably am writing it for the most compliant browser, as you say.

I don't know what "hacks" means to anyone person but I do know that in the Java Script that I wound up implementing (sucker tree vertical), the author of the Java code noticed work-arounds necessary due to a FF bug.

At any rate, I gave up on the more complex one that caused the question and turned my attention to a piece of code that was far more flexible from an end user point of view. My client is pretty new to HTML and knows nothing about CSS. They will be modifying the navigation occasionally and, if I couldn't explain how the three CSS scripts and the Java Script worked together to accomplish a menu, I sure didn't want to have to try to explain it to them.

I'm happy with the result, and so is my client. I guess that is all that matters at the end of the day, right?

Cheers!
Marj Wyatt

[jscheuer1]

I did touch on what I (and many others) consider the definition of 'hack' in this context. But to elaborate (and I will stress again, in this context), a hack is something that relies upon an undocumented browser peculiarity, absent in other browsers, in order to get it to do something that it would not otherwise do, in order to overcome some perceived lack in said browser.

This is a workable but limited (to the short term) strategy, because browsers continually upgrade, almost always trending toward greater compliance with standards.

It is far better to write standard code that will accomplish one's objective in any compliant browser. Then if there are problems, mop up with conditionals for IE (which are a documented part of the IE browsers, and so will presumably continue to be supported in it).

I think I see what is happening here though. It sounds like a situation where you didn't write the script, yet it claims to require a hack for FF. If it were written properly, then probably it may or may not require a conditional style or code for IE, instead of a hack for FF. That's basically all that I was saying.

If, on the other hand, you are introducing your own hacks for FF to get things to work, most likely you are doing something wrong.

Oh, and if you and your client are happy, I'm happy.

[marjwyatt]

Hey John,

I did write my own CSS style sheet. I did not write the menu script. I needed to have something flexible with levels and Dynamic Drive supplied just the right thing.

Here is a link to the article describing the problems that others, including myself, have had with images on FF. I created a division class and appended it after every division and all my images showed up in both browsers. Whether or not it qualifies as a hack is not certain to me. I can say that the site passed W3C compliance withouth a hitch.

http://www.webmasterworld.com/css/3359341.htm

If you'd like to take a look at the site that I have been laboring on, it can be found here, at least until my client gets done with her content porting from the old template-based system she has been using:

http://doggietreasures.mildlymystified.com/

Thanks to all the nice people who participate and share code at Dynamic Drive!

Regards,
Marj Wyatt
Skype: marjwyatt
URL: http://www.marjwyatt.com

[jscheuer1]

That problem, pointed out by your first link, even states that FF is correct in what it is doing. A float has no layout height unless one is specified. One can get it to act like an element that's not floated by clearing the float after the intended content of the float. So, doing so is not a hack. IE will sometimes add what is really unexpected layout height to floated elements. For a designer who already knows how to properly use floats, this can present problems. It can sometimes require that some markup code and/or style be added via IE conditional comments as a workaround. In most cases though, properly floated and cleared elements will behave as expected in IE as well, so it's not as big a deal as it might seem.

I do remember though, when I first encountered this, that it seemed to me at the time as though FF browsers (all others besides IE really) were the ones that were messing up.

Now, as to your page, this is the only css 'hack' I see, and I believe it came with the script:

/* Holly Hack for IE \*/
* html .suckerdiv ul li { float: left; height: 1%; }
* html .suckerdiv ul li a { height: 1%; }
/* End */

It's a good example of what I was talking about. When it was first written, it worked as intended. However, depending upon whether or not it's used with or without a valid URL DOCTYPE on the page, it will have different results in IE 7, which didn't exist when it was first formulated. This may or may not present a problem for any individual page in IE 7, as fortunately - in many cases - the very problem this hack is meant to deal with disappears under the same situations where its use is ignored by IE 7, but there are sure to be some other cases where it actually produces a problem in that browser, not to mention IE 8, future IE browsers, perhaps even some other browser.

If one were to include it only in a separate stylesheet - say oldie.css, like:

<!--[if lt IE 7]>
<link rel="stylesheet" href="oldie.css" type="text/css">
<![endif]-->

and always use a valid URL DOCTYPE for the pages, it would be a much safer proposition. This is because only IE 5 through and including IE 6 would ever even look at it.

[marjwyatt]

Once again, thank you.

I've only been designing CSS websites for about a year now and, with each one, I learn something new. I suppose it isn't unusual to borrow code from a previous design and copy it into a new one where it is needed. The truth about any software development is that tricks must be learned along the way, when the need to learn them arises.

I'm someone who learns better by doing than from reading how to do. This creates an iterative process which others might find tedious. (smile) I am very grateful for sites like Dynamic Drive, as well as w3schools, where there is depth of knowledge from which to draw when I get stuck. I've also been astounded by the amount of really good information online about Adobe Photoshop trips and techniques. I resisted learning how to do graphics for a long time. Now I find them to be a fun challenge.

I'll pull the Holly Hack out of the suckermenu script and put it into an external style sheet. This should not be difficult as all the suckermenu code is already external to my stylesheet. And, you were correct with your assumption that I did not write this script. If there is someone on the site who maintains this library, they may want to take a look at with is in the download area.

Have a great rest of your year and may your 2009 be filled with abundance and joy.

Marj Wyatt