Mozilla hates me...

It seems to be a javascript/layers problem.

I can't belive I am saying this, but it might be better to do this in flash

note in mozilla (at 800x600) you are able to scroll down, in IE you aren't, so miss all the bottom links. site layout is same in both

You are exactly right, it would be a lot easier to build this in flash. This is a fun project for me and a challenge which is why I am doing everything I can to stick with html/javascript to create this game.

If it is determined that it is impossible to make the cross-browser compatible then I will just do a browser check and provide an error message to all non-IE users. I am sure that someone here has used layers in Mozilla before and will be able to tell me exactly what I'm doing wrong.

Everytime I build something that works with 800x600 browsers I get complaints from almost every user that it is too small for all other users. Somebody always explains how they can barely read it in their 1600x1200 resolution. I know it is probably a bad idea, but I have given up on building anything 800x600 compatible.

The trick of making sites work in IE and Mozilla is to make it work in Mozilla first and then hack our way through IE compatibility. That road is way shorter than IE to Moz.

Has anyone manipulated layers in Mozilla using javascript? If so, can you please provide me with some sample code of what worked for you?

Thanks.

A couple of problems I can see:

nOpac = objID.filters.alpha.opacity;'
Brings up an error in the Javascript Console in Mozilla. The problem is you're using a "filter" -- it's a non-standard, IE-specific extension. The equivalent of this opacity filter in Moz is -moz-opacity (it's prefixed with a '-' because it's non-standard too). Either you forget about implementing fancy CSS-Javascript tricks, or you write a tedious, fragile script that detects the client type and uses the appropriate object model.

if(eval('secCover' + i + '.filters.alpha.opacity != 0')){'
Again there is a filter being used, but that's not what I'm pointing out here. I see you've resorted to eval() because of the naming scheme you've used for the page elements; this isn't the cleanest solution anyway, but it may also break in some cases. Look into using an array of elements instead, or exploiting child and sibling DOM selectors.

Some reading:
http://developer.apple.com/internet/webcontent/dom2i.html
http://developer.apple.com/internet/webcontent/dom2ii.html
http://developer.apple.com/internet/webcontent/objectdetection.html
http://www.cssdrive.com/index.php/examples/exampleitem/highlight_image_opacity/
http://www.alistapart.com/articles/pngopacity/

The same place where the alpha opacity is set for IE has the -moz-opacity set in the same section. I was under the impression that as long as I covered all browsers it would ignore the ones it does not understand and execute the ones it does. Does the IE version cause an error for mozilla?

Using an array would be very easy to put in place instead of the eval statement, but wouldn't it do the same thing? By your response it looks like the eval statement is frowned upon by veterans of the javascript world. Why is that?

I have read most of those articles and still have some questions. I don't believe my previous questions were answered in those articles.

It seems like it would be easier to manage the scripts if I include all browser support in 1 section without doing a browser check. I assume this causes problems because I got my scripts from other tutorial sites and they don't work.

Why do people dislike the eval statement?

I dislike the eval() statement because it doesn't exploit the usefulness of DOM selectors. It's unclean.

DOM selectors are discussed in the DOM I and II articles at developer.apple.

This is the error displayed in Mozilla's Javascript Console:

It doesn't matter that you've provided additional code for Mozilla -- the browser will still choke on what it thinks is a selector or syntax error as it tries to parse it anyway. What you need is to have a conditional if() or switch() that checks for the client type and chooses the appropriate selector path to use; subsequent code will use this path, hiding unrecognised ones from browsers. It's somewhat unreliable since browser sniffing has many fail-cases. Google for tutorials on browser sniffing, or study code at dynamicdrive.com.

The third link at apple.developer is an article describing a slightly different means of checking whether an object path is supported, which is to simply test for it. This method is less painful, but I don't know if it will suit your task.

Either way, it could get fairly complicated fast as you'll have to reconsider your script's processes and flow.

That is what I was expecting. Of all of the articles you posted links to I spent the most time with the apple ones. I will research checking for supporting objects instead of browser sniffing. That seems to be the best way to check for browser compatibility.

Thanks for your help.

Why not just DHTML the header?
... Can even do this in pure CSS

I'm not sure what you're referring to. Please provide more information.

For anyone in the future who has these problems - here are the answers:

Question: Can you use IE specific code and Mozilla specific code in the same function?
Answer: Yes. Mozilla ignores the IE code and IE ignores Mozilla's.

Question: Why do the layers fade in and out in IE but do nothing in Mozilla?
Answer: IDs must be associated with div, span, etc for Mozilla. IE allows tables to have an ID.