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).
damn i hate those tags (being -moz or -webkit or any other, mind you)
such a way to break the way. need a different browser each time if the dev doesn't take the time to use every single tag there is (and its NOT the dev fault here)
Thanks a lot! Playing with the code explained it well.
I think geoffschmidt's otherwise great explanation explained the score calculation a wrong-way around: checked score radio buttons start with zero height and when they get unchecked they grow to their 93px height.
I learned a few new things that were necessary to understand this:
1) States of radio inputs can be connected by name attributes and connected inputs can have an inverse state to each other.
2) Transition effects can be connected to checked/unchecked states (at least with "all" property)
3) Using a wrapper div with overflow:hidden you can create "a window" to a larger content that moves "behind" the window. I've seen this in some scroller effects, but as my CSS skills are quite bad, I couldn't yet write one without googling for some help.
Important detail: only in combination with an arbitrarily large HTML file, and only with arbitrarily many user interactions (i.e. the user needs to manually increment the state).
As such it's a pretty meaningless type of turing completeness. So, whereas in general it's undecidable whether a program completes (the Halting problem) if it's written in a turing complete language, for the case of HTML+CSS it may well be decidable for several reasons. Firstly; because the HTML file will be of limited (and in practice small) size, and secondly, because the interesting question is whether you can reason about the state _now_; not whether the document might reach arbitrarily many states were the user to perform infinitely many interactions.
Turing completeness makes hard to reason about a program; and indeed the weaker a language the easier it can be to reason about it - or, more practically - the easier it can be for the browser to determine boundary conditions and to simplify interpretation of the page. Indeed, ironically, Tim Berners-Lee points out the advantages of using weak languages: http://en.wikipedia.org/wiki/Rule_of_least_power
Saying that HTML+CSS is turing complete is kindof like saying finite state automatons are because the number of states is unbounded. That's entirely beside the point however; the point is that I can evaluate a _given_ FSA without turing completeness, not that an arbitrarily large FSA might take arbitrarily many execution resources (I mean, well duh).
Any given HTML+CSS combo is thus bounded in two ways; both by its own size, and by the fact that I don't care about eventual possible states reachable after infinite user interaction but just about the current state (or states very close to the current state).
You don't actually need a Turing-complete language to implement games. You can use finite state machines driven by keyboard/joystick input with images for each state.
This, besides websockets, is probably the coolest thing I've seen yet. I can' wait to get my mind wrapped around this so I can experiment with this concept. Perhaps, I can make something useful.
Possibly a dumb question but: who wrote this? I looked at the code and couldn't find any info on the author... Would love to get in touch with them and hear more about how they went about it, why they made certain choices...
Ask Author or Coomunity? Hold up, how does he listens to click events? There has to be javascript correct? I don't remember any pseudo classes handling click events?
Looks to me like they're all base64. Jsdo allows file uploads, so I'm assuming that (outside of novelty), the animations may not execute properly if the images aren't loaded. Using base64 ensures the images are loaded before the keyframe anims are rendered.
hm.
this only means that css has overgrown its own idea (but still without bringing real gutenberg typography into web pages - columns, gutters, flows .. u name it).
at certain point c++ templates became turing complete, so one could calculate pi's digits in it. After which all other languages started to spawn... away from it.
i used to love this game!! i played it with a real toy hammer and toy crocs when i was a kid :). it was a physical gaming machine! turning it into pure css! how far we have come!
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.