<!-- Lets load up prefixfree first -->
<script src="http://thecodeplayer.com/uploads/js/prefixfree.js" type="text/javascript"></script>
<!-- You can download it from http://leaverou.github.com/prefixfree/ -->
Granted all it does is add the vendor based prefixes to certain CSS3 attributes, but this particular demo does in fact use Javascript.
This is very impressive work - it's amazing to see what can be done with CSS these days.
But it's not very usable as a stopwatch.
A real stopwatch has a single start/stop button that triggers when pressed.
This stopwatch has separate mouse-driven buttons for start and stop, and they trigger when released. That makes it impossible to measure a very short time, and awkward to start and stop at precise moments.
It would also be nice if there were keyboard shortcuts for stop/start/reset - and those keyboard shortcuts should also trigger on keydown. (You could make a minor improvement on physical stopwatches by supporting both a single key for stop/start and two separate keys. The single key is convenient and familiar, but being able to use separate keys would make it easy to time very short events. This of course works only with the keyboard and not with mouse-driven buttons.)
Can all that be done in CSS? I suspect not - and if not, then why go to extra work to achieve a pure CSS implementation that's less usable? You could do it more easily with JavaScript, make it compatible with more browsers, and provide a better user experience too.
There's a reason it's called a demo. No one is actually suggesting that you use this as a proper stopwatch. Everybody already understands the limitations you specified.
But I'm fairly certain that not everybody understands the limitations I mentioned. You and I and hopefully most of the folks here, sure. But spend some time on the css-discuss mailing list [1] for an eye-opener.
Many of the members of that list seem to favor CSS-only solutions even when the user experience is inferior to what you could achieve with a sensible blend of CSS and JavaScript. And they're not just talking demos, they put this stuff into production.
I don't understand that point of view at all. I want the best solution for the user, and I'll use whatever tools are necessary to build it.
Well, in the situation you are describing I most certainly agree. CSS-only solutions tend to be quite lacking in real-world terms. But this was a demo and I saw no indication it was anything other than that. If you were meaning to aim your comment to people that think the way you describe then I apologize, but I didn't get that from your comment.
At first my inner neckbeard scoffed and proclaimed why? I looked at the source and realized I don't know jack about CSS3 and how easy something like this is to implement in less than ~150 lines of code was like ramming a sock down my inner neckbeard's throat.
I can't see the code because the account has been suspended. My inner neckbeard is shouting "Stop turning everything into a jack of all trades! Can't cascading style sheets just be really good at styling?"
This is very interesting, but I wonder if it falls under the domain of things that CSS should do, in a real app you probably shouldn't CSS so much. (This is not an affirmation rather a question!).
Even so I think it is a great proof of concept and the font style was cool idea.
My initial reaction was the same. But after I reviewed the code and saw how the magic worked, then I thought there was nothing wrong using the CSS this way: mainly the new feature of animation is utilized.
My point is that, this is indeed a cool concept, well written and does well what it intended.
The problem I see, it that at one point you my start using CSS for something that will eventually (without you prior knowledge) grow bigger and more complex outside of the realms/possiblilies of CSS, now you will have to re-write.
Call me a purist, but when you start using CSS for more that styling, you might want to re-evaluate.
That said, again, I think this example is awesome for showing the new feature of the CSS language.
Maybe I'll be the only one to say it, but this doesn't work with NoScript. Maybe this actually is a JS free Stopwatch, but the site doesn't work without JS enabled. Perhaps the title of this should be changed, or relinked to a JS free version?
It uses prefix-free, which is a script, in order to be cleaner-looking code. As the author says:
> The JS used is prefixfree - just to make the length and size of the tutorial short and easy. No images or JS are used in the stopwatch logic/display.
It would be trivial to make a new -really- JS free version, but it wouldn't be so easy to understand. It could be non-js in production, it just isn't for teaching purposes, so I am happy to accept it as a 'non-js' stopwatch.
I tried testing the same way too, and it failed on me. I think the code would not load properly without JavaScript enabled. The proof that it works without JavaScript is the empty box where you put your JavaScript code.
get a good host that has some bandwidth overage contingency in place to keep your site from going down. unless of course you don't really want traffic on your site.
It was a rhetorical question, basically. Almost nobody knows whether or not their commodity web host can stand up to an HN-like traffic surge until they actually get an HN-like traffic surge.
The alternative is to pay what might seem like a ton of money for something that they aren't going to need 364 days out of the year.
The page just got suspended in the middle of my page loading, half of the page loaded, CSS was not loaded. I refreshed the page and here's Account Suspended page.
I am wondering the same thing. Aside from being an impressive CSS3 demo what are the practical implications here? Will this make my site load faster compared to a js version? Will it likely be more responsive?
Back up! Seeing what people do with CSS is like watching MacGyver - it might be the wrong tool for the job but it's always impressive. Look, I built a gun with some rubber tubing, a rotten egg, and a duck!
Cloudflare is just the CDN in front of the site, it's not the web host. The source IP (direct.thecodeplayer.com) is in ServInt's netblock (http://www.servint.net/).
