And expect it to work in IE.
Fox likes it just fine.
And yes, I know clever use of eval is discouraged, but I needed it! No, really! I needed to encapsulate the event handling mechanism for a DOM object, shunting the event to a different controller object! eval was the only way!
Fixing the problem for IE caused a different problem for IE. I was calling a different event handler from one of my event handlers, but in the IE version of the event handler window.event.type is used, which caused a stack overflow. So, I took out the call, replaced with equivalent code, and moved on.
It now works in both fox and IE, with the new navigator. I’ll upload it after I’ve gotten a few more kinks out.
I had my wife play the game with the new navigator, and the only part that she did not find intuitive was my “revert” button. I had originally designed it so that if you were looking at a historical view of the game (by using the previous move or previous mark buttons), making new moves was not allowed (because it would mess up the rest of the history), so I made a “revert” button to restore the game to that point in the history.
Except that it turns out that the natural inclination of a player is to back up to the point they want, and then just start making moves.
I didn’t want to just make an auto-revert when making a move, because that might be a mistake on the part of the player. However, I it was clear that the revert button wasn’t the right solution, so I left the revert button in (although I’ll likely take it back out) and made a prompt if the player decides to make a move when looking at the history. This way, I prevent mistakes on the player’s part by being too hasty with a move while scanning the history, but I also don’t frustrate the player with unintuitive controls.
In the next few days, I should have it updated on the site, and I should have an updated feature list left to implement. I’m feeling it start to take some of its final shape at last.