slayeroffice - web experiments gone horribly awry

12.17.2004 - Focus Slide Menu

Long time no update...I'd like to say that it's because I've been hard at work doing something cool, but the sad truth is that I fell victim to the addictive drug that is World of Warcraft and I've been playing it in every moment of spare time I can find. I even have Kate addicted to it.

Honestly though, I've not had this much fun in an MMORPG since EQ first came out, and I smoked that crack pipe for four long years.

That said, I'm not posting to just inform you of how completely awesome WoW is - I actually have an experiment to post.

I was lurking in a dev forum who's location escapes me and reading a thread about an idea for a menu that would have a "lens" that would slide over the currently active menu item. Seemed like an interesting idea to me, so I tossed something together.

The Focus Slide Menu is a horizontal unordered list - when an LI is moused over, a DIV element that is created via script slides over it and...yeah, ok - not that exciting, but then what do you want from me? I've been hunting Murlocs all day.

Nice to see you back in action Steve :) I like this script, but I'm less keen on the 'sizes in script' factor. Perhaps the script could detect the width, padding and margins of the li's and use that to set the SLIDE_STEP and SLIDER_DISTANCE variables. Also, it would make more sense* for the script to treat any li with and id of 'active' as the active array item instead of setting that in the js file.

* No one wants to serve dynamic js files just to set the current nav item, do they? :confused:

This wasn't meant as a criticism, just some possible improvements to make the script more robust and reusable.

p.s: your link to the css file is 404; you've set the href as focus_slide.csS

Slay some pixel gremlins for me :)
Posted by Andrew K. on December 18, 2004 @ 6:18 am

Thanks for the feedback, Andrew.

The SLIDE_STEP var is more of a speed setting, and I left it hard coded as a means to tweak the script for personal preference. The higher the number, the faster the slider moves, etc.

There is no SLIDER_DISTANCE var, so I'll assume you mean SLIDER_WIDTH - and you're right, I could calculate that based on its offsetWidth.

As for the active id, I don't think that would be an issue since the script only takes action on LI's it finds within the UL with an id of "mContainer" so no other LI's in the document will be affected by it. So, you could add more, or remove some and the script would still go about its business without any modifications.

Does that answer your questions or did I miss them completely? (link fixed, btw - thanks!)
Posted by Steve on December 18, 2004 @ 3:56 pm

Ah, ok -- I misunderstood the purpose of SLIDE_STEP (I didn't really dig into how it was used, just saw it at the top...).

"There is no SLIDER_DISTANCE" -- oops! Glad you worked out what I really meant.

I think you may have misunderstood my point regarding the active li. I'm assuming that var is used to set which li the box is over upon load? If so, it would fit more easily with common "CSS menu" practice to have the script iterate through the li array (children of mContainer) and if one of those has an id of "current", "active" or whatever, it sets that array item as 'activeLI'. That way, the menu could still function like any other CSS list menu without javascript by indicating the current page through a style difference associated with '#mContainer li#active {...}'.

Another improvement I thought of is to make a wrapper function that triggers recalculation of the width. This could then be attached to any of the popular 'text size style switchers' so that the menu would still look good with larger text. If there was an onTextResize event to attach the calculation function to, that would be even better. Somehow I doubt it though, or it would have been used for sIFR.

I've got a crazy idea for this script (hint: client side XML/XSL + this + image cross fade); but there's no way I have time to tinker until the new year. Damn.

I'll keep you informed though :)
Posted by Andrew K. on December 19, 2004 @ 1:14 am

Ah, ok - I'm with you now. Thanks again for the feedback - a point version update may be forthcoming if I can pull myself away from WoW long enough =P
Posted by Steve on December 20, 2004 @ 3:32 pm
Hi Steve, the slide menu looks cool, can i use the code on my site? and is there a way to make the sliding div hover over the current link?
Posted by Paul on January 8, 2005 @ 1:55 pm
Sure Paul, you can use it. All you should need to do for the hover is add an onlick event to the links that would prevent any subsequent sliding. Let me know if you need a hand with it.
Posted by Steve on January 8, 2005 @ 5:08 pm
Is there a 'right' way to get this to work with dynamically generated unordered lists? Case in point, if you look at when the slide os over the 'Tools' item the slide nearly butts up to the Login item. The Login item is dynamically generated. If you are logged in then the item is Logout.
Posted by Jason Borgmann on January 19, 2005 @ 2:41 pm
You could increase the marigins on the LI's, which would make the list longer horizontally. Or, you could change the size of the floating DIV element to be more in line with the offsetWidth of each individual LI or anchor tag when the sliding stops - that might require some additional tweaks to the code to get the placement right.

You might also want to take a look at Pauls implementation here:
Posted by Steve on January 19, 2005 @ 3:42 pm

Nice rework on the cross fade script. One question though. is there a way to define the images within the javascript instead of on the page itself? I have found this can create large page sizes and load times. I was also thinking that it would be nice if it only preloaded the next image because some people might not stay on a page for all (say 20 ) images. Preloading all 20 would then be a waste of bandwidth. thanks!
Posted by ethan on September 12, 2006 @ 8:04 pm

Comments have been closed for this post.