Great, that was fast. Ok, script on DD updated to the latest build at this point: http://www.dynamicdrive.com/dynamici...menu/index.htm
Available at: http://www.webtech101.com/index.php?page=effect-menu
version with included documentation: http://www.webtech101.com/uploads/mleffect/mleffect.zip
- removed one of the effects(blink) for various reasons
- Two new switches trail and left(details on linked page)
- delay switch wait time has been increased
- onload event handler modified to play nice with other scripts
- IE conditional comment changed to not effect IE7 which does not need it
- CSS almost completely re-written to work better and look nicer
- Various bug were fixed
- Browser detection removed(in favor of a try..catch)
Looking good! I'll get to updating this script in the next few days.
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.Code:if (document.getElementById) var el=document.getElementById('id'); else if (document.all) var el=document.all['id'];
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?
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.Originally Posted by jscheuer1
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.I am assuming that you've worked out a way to carry out the functionality for this in FF.
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)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 is exactly what I am using it for.The timeout is something I hadn't thought of will look into.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?
This setTimeout/clearTimeout scheme is used with many of DD's menus. An example is in AnyLink Drop Down Menu:
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.
The basic idea is: