Use this area to submit an original
DHTML or CSS code for other visitors of DD to utilize or critique. Furthermore,
through this method of submission, your code may be added to DD's
DHTML or
CSS Library section if deemed
useful by the admin of DD. Guidelines for using this forum:

This forum should only be used to post an
original, fully functional and "practical" script. It is not for
putting up experimental or the rudimentary "my first script."

To submit a code, fill out the information
on your code as outlined in the instructions. For the actual code, ideally
you should just enter a URL to the full working demo, to make it easy for
others to check it out. However, if this isn't possible for you, you can
also submit your code inline on the forums, by attaching it.

If you're attaching the full code inline in
your post, please following the following conventions whenever possible:

For straightforward code, just attach it as a single .txt file

For code that consist of both code and images/other media, zip up
all the files and attach it as a .zip file

Should you need it, this forum supports file attachments of the
following type: .txt, .zip, .js, and images (.gif, .jpg, .png etc).

Again, if possible at all, it's best just to submit the URL to the
script instead, for ease of review/ critique by others.

By submitting a code, you declare that
you're the original author of the code, and grant Dynamic Drive to right
to include and modify the code for possible inclusion in our code library.

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

This is becoming and looking to become an even more useful script. I applaud the emphasis on style over script to the point of the navigation being available to non-javascript enabled browsers. That is a really great move! Moving away from browsers detection is also a very good idea. However, try {} catch(){} is not usually required and will create problems in older browsers. The real use for try/catch, in my opinion, is for debugging a particularly difficult error. A better substitute for browser detection is object detection, sometimes also called feature detection. The classic example being:

Generally, anything that you can test for with try/catch can be tested for in this sort of way. Sometimes one needs to get a bit creative, like checking for the 'typeof' something before processing it but, this is also object detection and doesn't require any particular browser, just a browser that recognises what objects you are using and what objects you want to use in conjunction with them.

Yes, I would rather use object detection, but I can't. I need the try catch to counter a Firefox bug(I did eventuallly find it in bugzilla, and has been open since Firefox 1). If a script even tries to use object detection on any property of relatedTarget(property of an event) when relatedTarget is a textarea Firefox throws a security error. That is why it was so hard to fix. How do you detect the problem before it occurs? My solution is to not try and wait for firefox to throw the error.

I'm not clear on this bug, could you supply a link to it at bugzilla? However, in FF, the type (comment, text, HTML element, whatever) of a node can be detected before anything else is done to or with it, so can its value - which must be null for it to be an element.

I realize that identifying it as the relatedTarget() may be too late for this sort of detection but, with a bit of thought (combined with the predictable flow of the code involved), a way could probably be found to identify and test it before it is accessed via the relatedTarget() object.

Once that is determined, it may become unnecessary to even use the relatedTarget() object.

hmm...can seem to find where I had it bookmarked.With multiple computers and multiple browsers on each I may never find it. However, I have prepared a quick demo here. This shows exactly what the bug does. As far as I can tell it occurs in every version of firefox I have (1,1.5,2 RC2). Simply move your mouse from the textarea to the div and back, and watch the errors pile up.

Hmm, that does on its face seem a good candidate for try/catch. However, it doesn't work at all in IE, even when you use window.event.relatedTarget. IE has mouseenter and mouseleave events (that don’t react to event bubbling), specific to that browser (from 5.5 on) that may or may not be of any use in this case. I am assuming that you've worked out a way to carry out the functionality for this in FF. If that is the case, that method probably could also be used by most other browsers, eliminating the use of both relatedTarget and try/catch.

I'm thinking that this could be real useful in preventing a sub-menu from disappearing if its trigger is moused out but the sub-menu itself is being moused over and visa versa. A variable timeout delayed disappearance function that gets cleared by the appropriate subsequent mouse over(s) can accomplish this same thing. Were you using it for anything else?

However, it doesn't work at all in IE, even when you use window.event.relatedTarget. IE has mouseenter and mouseleave events (that donít react to event bubbling), specific to that browser (from 5.5 on) that may or may not be of any use in this case.

IE supports window.event.toElement(mouseout) and window.event.fromElement(mouseover) that the same thing as relatedTarget. That is what I am using in the full script.

I am assuming that you've worked out a way to carry out the functionality for this in FF.

Yes and no. When I was using browser detection I had another version that still used relatedTarget, but did not try and access any properties. This avoided the bug in Firefox.

If that is the case, that method probably could also be used by most other browsers, eliminating the use of both relatedTarget and try/catch.

That was what I originally did until I found out that it didn't work in Opera.(or IE5, but I don't worry about that browser)

I'm thinking that this could be real useful in preventing a sub-menu from disappearing if its trigger is moused out but the sub-menu itself is being moused over and visa versa. A variable timeout delayed disappearance function that gets cleared by the appropriate subsequent mouse over(s) can accomplish this same thing. Were you using it for anything else?

That is exactly what I am using it for.The timeout is something I hadn't thought of will look into.

The code is a little confused (I didn't write it) because the (e) parameter is included in some of the functions but, not used by all of the functions it is included for and things are a bit more complex than necessary.