Basically it's a bunch of animations that play simultaneously. For example, there is no actual timer. Instead there is an animation of a bar filling up, and an animation of a "game over" screen doing nothing for a few seconds, and then sliding onto the screen. All of this is done with CSS keyframes.
Each of the alligators is actually a radio button styled to LOOK like an alligator, including an animation to move up and down in a fixed pattern. When you check the radio button, it changes the style (through CSS rules conditioned on the checked state), which changes the animation to take the alligator off the screen.
Now, the scoreboard: For each alligator radio button, there is a corresponding radio button in the scoreboard, paired up so that checking the alligator button unchecks the scoreboard button. The scoreboard buttons are stacked on top of each other, and unchecking them causes them to animate their height down to zero. This effectively computes the number of checked alligator-buttons and outputs it as the height of the element. At the bottom of the stack is a strip of images for scores 0, 1, 2, etc, so that as the buttons are unchecked, the right one moves up into the display area.
Finally, the "play again" link at the end just reloads the page.
Your explanation is correct, only you got scoring direction mixed up: initialy radio buttons for scoring are checked and have zero height, when "enemy" is clicked, corresponding score input is unchecked, gets height set and pushed numbers panel down.
I've made an illustration: http://jsfiddle.net/72bbx/
The difference is that there initial height is non zero—just to make radio buttons visible.
It's done all the time, mostly to reduce the number of requests needed. It's similar to spriting, but can be even faster depending on the images you need.
Yes, there are fewer requests that way, but the cost is an increase in the total data size. Using a single sprite sheet for all the images would probably be faster in most cases. However, there is the matter of convenience (it's nice being able to have just a single file with no dependencies).
It depends on what you're doing with the image. You can't always tile a sprited image for example, which is a nice advantage for base64 encoding. Size wise they're pretty similar once you count gzipping, though you do have more overhead on base64 since each will have its own set of image headers vs just one for the sprite.
The best is a single sprite sheet encoded into the source file (I believe this is what the Cappuccino framework does for some of the images that make up some UI elements).
Basically it's a bunch of animations that play simultaneously. For example, there is no actual timer. Instead there is an animation of a bar filling up, and an animation of a "game over" screen doing nothing for a few seconds, and then sliding onto the screen. All of this is done with CSS keyframes.
Each of the alligators is actually a radio button styled to LOOK like an alligator, including an animation to move up and down in a fixed pattern. When you check the radio button, it changes the style (through CSS rules conditioned on the checked state), which changes the animation to take the alligator off the screen.
Now, the scoreboard: For each alligator radio button, there is a corresponding radio button in the scoreboard, paired up so that checking the alligator button unchecks the scoreboard button. The scoreboard buttons are stacked on top of each other, and unchecking them causes them to animate their height down to zero. This effectively computes the number of checked alligator-buttons and outputs it as the height of the element. At the bottom of the stack is a strip of images for scores 0, 1, 2, etc, so that as the buttons are unchecked, the right one moves up into the display area.
Finally, the "play again" link at the end just reloads the page.