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.

So this works, but when I replace $('.CurrentSelection').hide(); with $('.CurrentSelection').click() it doesn't work. I have read many solutions saying I need to include .live or .on, but I don't know where to add it in. For instance this doesn't work $('.CurrentSelection').on().click()

.click() is fine there. However, I think it does something other than you imagine. It doesn't click the element. It executes any previously assigned jQuery click event(s) for that element. If there are none, it does nothing. It can also be used to assign a click event to an element, see:

The Following User Says Thank You to jscheuer1 For This Useful Post:

Amazing!! Thanks so much John! I think replicating that on my own would have been a mind bending experience that wouldn't of resulted in something that good. Cool how it can jump from the last step, to step 1, then back to the last step again. Sent a tip

The only thing I changed was keydown to keyup, keydown works better it some ways because you can just hold down the right arrow/left arrow key to navigate, but it can make the page go crazy by registering too many keystrokes at once. If there's a way for it to stop it from registering a new keystroke until it reaches the next container that would be ideal, but really this is fine as is, I might look into that more later though.

Great! And thanks. I think that's a good way of dealing with keydown/keyup I hadn't thought of that. I did notice how holding down the key with keydown caused it to repeat, sometimes a lot. The alternative is to set and unset a flag. On keydown set the flag, if the flag is true, subsequent actions are not carried out. On keyup the flag is set to false. So you still need keyup. Not sure if that's an improvement or not. The less code and flags needed, generally the better. I always thought keydown was the way to go for anything like this, but that's leftover from years ago, before I ever started working with jQuery, something someone I respected said in these forums. It might have been more applicable then and/or to the specific situation then than it is with this code*.

BTW, the jump to number thing will still work without javascript, but of course not the arrow keys.

And, just looking at it again, I left an extra variable in there that's not used and you of course copied it:

The highlighted can be removed. It doesn't really hurt anything though. I had been using it in an earlier version of the code.

*I remember why keydown is preferable. If you need to cancel the default action, you have to use keydown. If the page were to have a horizontal scrollbar, the arrow keys would still move it left and right with keyup. And your code is more responsive with keydown, rather than waiting for keyup. So it's worth doing the flag thing to prevent repeats and to 'listen' for both events.

I'll look into setting a callback also (implemented the new code, though holding down an arrow key won't jump to the next one until keyup still). I think the logic behind using keydown also is that in some cases the user might not think they've registered a keystoke (when using keyup) until they release the key, or just that with keydown the event happens sooner than keyup (sooner=better).

A feature that would be cool to add on later, though seems a bit too complicated to focus on it at the moment, would be:

If the page could detect where the user has scrolled to on the page, so that when the user hits the right arrow keystroke it would jump to the next element (the next step), rather than starting from the beginning at step 1. For instance, if you were looking at step 6 (by scrolling to the step, rather than using the jump list or arrow keys to navigate there), then you hit the right arrow key and it would jump to step 7.

The downside to the above feature is that the easiest way to implement it (though would still be complicated..) would be to have it so that the 2 classes (CurrentSelection and activemap) are being added/removed while you move up and down the page. The problem with that is I wouldn't want the containers to highlight as you are scrolling, I would only want that to happen when you hit the keystroke.

Imgur is actually having the opposite problem. When the arrow keys are needed (or at least would be nice) in a comment section's on page editor (like the posting on page editor here), they're still being commandeered by the Imgur script. That's actually a good reason not to use keys for anything in javascript, they might be needed for something else and not be available at that point for their native purpose. They should be able to solve their particular problem by checking the target element, if it's a textarea, the part of the script that usually uses the arrow keys can return before it cancels the default behavior of the key(s) and before it does any navigation. But you cannot always anticipate all of the possible uses the key(s) you want to commandeer might be put to. So generally it's better to find another way. With your page, since it has no other features that might need those keys, it should be OK in most cases. But it would be better to have all of the images be shown in one spot in turn (a slider) with a next and previous button that can be clicked or focused on and hit enter to activate. The jump to buttons could also be used to navigate this slider. That's for javascript capable browsers. For others, what you have is good. Both could exist on the same page with the same markup. Javascript can take the vertical list of images and compress them into a single viewing area that acts like a slider. Non-javascript users would see what you have now.

Anyways, I played around with your idea about detecting the scroll of the page. Not changing the active map color is easy (that class isn't required in order to keep track of the current image), some other parts of it were tricky. I also added some styles to get the rounded corners in IE 9+, as well as modified others to get the griffin icon to offset better. And I changed things so that when animating, you're brought to the top of the HR, not the top of the image, looks better I think. Finally, I changed when the color of an active map changes, waiting until after it had finished scrolling. Here's a demo (paste the URL into your browser's address bar and hit enter):

The Following User Says Thank You to jscheuer1 For This Useful Post:

Very Cool! Works great. Appreciate you touching up things for IE also, that's never fun heh. I've been meaning to re-work the layout/theme a bit and never got around to much browser testing aside from Chrome/Firefox. Sent a tip.

It works just like I had hoped! Although there's one, hopefully kind of minor, change that would be nice to implement. I incorrectly worded my vision of what I was shooting for when I wrote

if you were looking at step 6 (by scrolling to the step, rather than using the jump list or arrow keys to navigate there), then you hit the right arrow key and it would jump to step 7.

I think it would be better if it highlighted the current step first, before jumping to the next step. So, if you were looking at step 6 (navigating there using page scroll) and hit an arrow key, it would highlight step 6 before moving on to step 7 (or step 5, if they hit the left arrow key).

Aside from that it works great to my liking. The hr offset I agree with, had a similar idea in mind when modifying the code before (offset it 10px from the top of page, rather than hr). I hadn't focused on that just yet as I may include a feature soon where on page scroll the jump list at the top would float to the right or left of the container, so it that it wouldn't be fixed at the top of the page at all times.

EDIT: I think really what I'm shooting for is for the left/right arrow navigation on page scroll to be as similar to the Imgur ex here: http://imgur.com/a/sArwl . They seem to using an approach that's slightly different from my amended suggestion, where using the left arrow key will navigate backwards, and using the right arrow key focuses on the current element and then navigates forward. Really though, I'm just trying to get it to be as intuitive as possible, which is the end goal.