Good catch, though for what it's worth Apple's actually has the correct time on it. Hers appears to be doing some initial date/time setup via JS, but it doesn't appear to show the correct time, at least for me.
Built an analog CSS clock of my own without the use of any pre-rendered images (http://attasi.com/experiments/analog-clock/). Surprisingly, keeping time with CSS is far more accurate than with JS. The animation is also waaaay smoother.
It's also a terrible clock. It is incredibly hard to figure out the actual time when you have to look in 3 separate places for each part of the time. It's pretty, but borderline useless, just like flash.
Exactly... I don't think anyone in their right mind would write a clock webpage to seriously replace the built-in system clock on every PC/device out there!
this can be greatly improved (losslessly) using http://punypng.com / http://www.smushit.com/ysmush.it/ / downloadable PNG recompressing software. I tried it on several files on this site and some decreased in size by more than half.
I wouldn't say it's crazy big. Bigger than 99% of one page sites? Sure. I've got a 50mbps connection and even with a far slower one, this would only take a few seconds to load.
It took me a couple of minutes on a 3G cellular connection.
It was worth the wait, for sure, but due to the way it rendered, I felt like I had to watch the whole thing because I didn't want to miss something neat.
It could (and should) definitely be optimized a lot, but as a proof of concept, I'm not going to quibble over file size, even if I'm negatively impacted.
This was super cool on my laptop. But there was mention of HTML5/CSS3, so I just had to check it out on every mobile device I had handy. Uh oh...
Doesn't work on Android phone (3.2.6, Nexus One). Pendulum only runs a half cycle, hour/minute hands don't move at all and point to incorrect time. Low frame rate overall. Loads in different places on the screen, including half-way off the right edge, depending some factor I haven't yet deduced (zoom level, perhaps?). Doesn't allow any panning or zooming once loaded.
Doesn't work on Windows phone (Mango, LG Optimus Quantum). Pendulum animation doesn't run at all.
Works beautifully on iPad 1 in landscape. In portrait, background shows a visible seam around the clock.
I really like the design, and appreciate the effort. I just find it a little bit kooky that the OP promotes the non-use of Flash, touting instead technologies that are supposed to work much better (or at all) on mobile devices. It's Alanis Morissette Irony.
It seems like if you wait long enough the gears start moving. On Chrome I just saw the closed aperture for several minutes and gave up, on FF I saw the arm and pendulum moving but that's all, 'til I came back several minutes later and the gears were moving. Haven't been able to get that "gear moving" effect again tho. I think file-size/load-time is actually a problem in this case, even as an art piece, as it's taking so long to load I'm not even seeing the art.
A couple other things: the apple clock is using javascript as well, not just css3 (tho they could if they tried). This one... I didn't dig far enough to see if it's used anywhere in the clock but the hands and pendulum are just css. Remember kids, html + css + javascript != "CSS3" :)
Further, HTML5 is nice but it's being used pointlessly here:
<article class="layer zero">
<div class="blurred gear one"></div>
<div class="blurred gear two medium reverse"></div>
<div class="blurred gear three large"></div>
</article>
This is an "article?" HTML5 to add semantic meaning is good, using it for no reason... I don't see the point. Overall, KUDOS to the designer/developer! Extremely impressive regardless of any of this.
Closed aperture issue should be fixed now.. (was an issue with the analytics platform going down due to traffic, not the size of images (though that is of course pretty big))
The most impressive bit of HTML5 I have run across lately is turntable.fm. Yes, I'm probably late to this particular party, but I was very impressed when I realized the interface is done entirely in HTML5.
You just have to get around the fact that they don't seem to be handling scaling very well and, as a result, the site becomes defunct every few minutes.
In the new Chrome beta for Mac, when you pull the page down too far to see the grey browser background, Chrome messes up and the background appears as a smear of red.
Although unbelievably impressive. This kind of shows me the opposite of what the site was going for. Although the new protocols give us a lot more freedom of expression with animation support. The browser rendering time is just not there yet. Any browser that can handle that clock in a reasonable amount of time also has flash on it.
I'd love to add this type of tech to our online alarm clock site (http://sleep.fm). Though and correct me if Im wrong - HTML5 doesn't have a cross compatible audio solution available; one as solid as flash?
Yes you are wrong, the cogs turn the pendulum's speed into three different speeds - one for each hand. Some/most/all (not sure) clocks with pendulums have weights that allow you to alter the weight on the pendulum to adjust if your clock is running too slow or fast.
I was pondering today why no-one really knows about or even uses it.
As a bit of a general question to everyone, did old browsers not support it or something? Or do people prefer using relative urls over absolute style ones?
For those interested, the reason the old google analytics snippet wasn't using this instead of document.write:
There is an edgecase bug in IE6 that causes a dialog to blow up… under some security settings (unsure if they are default) when requesting form the non-'ssl' subdomain
So looks as if it's fine to use if you're not supporting IE6.
The new GA snippet uses different domains for the two modes so it can't be used.
Thanks for adding the -moz prefixes too! (Yes, Firefox supports CSS3 animations now; most web developers only use the -webkit prefixes though, sadly. Glad to see this is changing.)
Also, in chrome, try to inspect the DOM using the built-in inspector: the diaphragm will close. If you click again inside the window, it'll open again.
It's cool. But let's admit it wouldn't be impressive if it were written in Flash...because Flash makes it relatively trivial to write something like this.
So is it only impressive because it doesn't use Flash? And if so, what does that say about how wise a decision it is to start trying to replicate complex animation in Javascript, CSS3 and Canvas, just to keep Steve Jobs happy?
Arguably, Jobs chose to eliminate Flash from the iPhone specifically so that casual games would have to be written natively and sold in the App store, and couldn't be played on the open web. Since Javascript runs at about 20% the speed, the reasoning was that the only decent games would have to be written in Obj-C. And that still holds true, despite legions of hackers trying to ride this HTML5 pig as if it's a thoroughbred stallion. It'll just never be up to the task. I could write this thing in about 3 hours in HTML5/CSS, not including modeling and rendering time. But that's also because everything in it has a centered pivot point. If it didn't, it wouldn't work in IE 6, 7 or 8.
So, nice job, but was the only point really to show that you can do something Flash-like in HTML5? If so, what's the point again?
I have to agree. Would anyone be impressed if I did this in ObjC / CoreAnimation? It would be simple enough.
Posts like this remind me of the old "year of the Linux desktop" crowd: People demonstrating how Linux can (often poorly) do the baseline simple things that other operating systems have been doing for years or decades.
Meanwhile, those other desktop operating systems were leapfrogging ahead.
>Meanwhile, those other desktop operating systems were leapfrogging ahead.
I think this is quite fitting for how Flash is developing out of the spotlight now as well. I think that the Flash exodus - if it will mean less designers doing ridiculously processor intensive banners - ultimately is beneficial for the future of the technology itself.
Yeah, the only difference being that every company besides Adobe is choosing this as the new web standard -- instead of doing what they should do, which is writing browsers compatible with ECMA-4/5 standards, and making either AS3 or JS2 built in with a genuine screen graph so animations don't have to be tied to this absurd 1994-era DOM for the next decade or longer. Short of that, they should allow any and all plugins necessary to run what users want to run, and stop their campaign of demonizing Flash. I realize Apple's made millions off breakout games that people downloaded because they were blocked from playing the free versions in Safari, and I don't blame them for being Machiavellian about it, but I also don't see a reason to feed the beast by pretending everything's hunky-dory with the ramshackle decaying non-cross-platform crap they've left developers to work with in the webkit/HTML5 stack.
>...Jobs chose to eliminate Flash from the iPhone specifically so that casual games would have to be written natively and sold in the App store, and couldn't be played on the open web....
This is such an important point. And very illustrative of the attitude of Apple.
If any other company did this, they would be villified far and wide. But because we like apples products - it is overlooked.
This is not true at all. Jobs didn't include Flash on the iPhone because of its performance requirements.
Apple didn't realize how important the App Store would be to the device's popularity when the iPhone initially launched. It appeared that the intent was to keep it a closed, curated platform where only Apple and its partners could ship products for it. This was the strategy that they had established for third party iPod clickwheel games.
In fact, Apple initially raved about how great "Web Apps" would be on the device, and showcased crude web based games at WWDC 2007.
It was largely due to developer outcry that Apple responded with the App Store, and it was a much larger hit than anyone predicted. The business savvy was in their ability to roll with it.
the SDK was planned from the beginning, not the result of developer outcry—though it certainly didn't hurt. apple had to make sure that the APIs were solid before releasing them to everyone. that takes time.
The SDK was around from the beginning, but planned for a curated channel of third parties that Apple selected itself. Apple wsa incredibly worried about security issues on the device, and initially tried to satisfy everyday developers with: http://www.apple.com/pr/library/2007/06/11iPhone-to-Support-...
The outcry was so fierce and sustained that around 3 months later, Apple backpedaled on this strategy and Jobs himself announced that they would open the platform up.
Again, the performance requirements of Canvas, DOM, JS 1.5 and CSS3 are far higher than AVM2/AS3/Flash 10. They just take 5x as much processing power to perform the same graphics tasks. This isn't a fact in doubt, but I feel obligated to respond everytime someone brings up this argument. It's not true. If they wanted a faster platform, they would have chucked webkit and written JS2 or AS3 into their browser.
Well, with Flash they were also beholden to Adobe to fix bugs and optimize it for whatever GPU they wanted to use.
I'm not sure it does take 5x as much processing power, especially when you can ship things off to the GPU. You have to remember that these decisions were made a few years ago, and Adobe Flash video on mobile (where available) has always lacked the performance of native apps/HTML5 video.
As far as Flash mobile performance is concerned, the main issue at the time was constrained to video playback. I am not debating that Canvas is slow, as is the Flash 10 software-blitted graphics Stage.
Both Flash and Canvas are moving towards GPU accelerated rendering pipelines, and Adobe is also making proposals on the HTML5 side, like CSS Shaders, but that's a separate discussion.
My beef was the idea that Apple knew that third party games would be one of the most popular draws to their iOS products. Nobody did (except perhaps game developers themselves).
@doomlaser - it's interesting to hear the argument put that way, because nothing I use flash for involves video delivery (or very little of it). Video delivery is to flash what hot topic was to...whatever my favorite bands were in 1995. It's the generic mass market application of something arguably meaningful, useful, appealing and capable of changing the world. Below that are the banner ads. But in the middle, it's true, there's this wide audience for streamed video that should have been served by browser technologies long ago, and that Flash really should never have been a part of, except that it filled a void as the only plugin widely enough adopted to support cross-platform video.
The loss of video to native browser technologies takes nothing away from the things Flash has to recommend it as a method for blitting graphics to the screen. It's one thing to try and do it with canvas and divs in Safari -- it's a joke getting things to line up, but it's not impossible. But if you want it to look the same in IE? A guy's supposed to run a startup and worry about Firefox reversioning every 4 weeks at the same time? Realistically, if I wasn't running my app in Flex I wouldn't have a company; I'd have a giant pile of IF IE statements and a bigger list of complaints.
So this clock is where the rubber meets the road, in a funny experimental way. It's got "no flash" in the title, so we can assume this is where an HTML5/JS proponent with some coding savvy thinks the line should be drawn; this is what can be achieved with the technology available cross-browser given the state of the DOM art. And I'm not saying it's bad. I'm just saying that it's nonsensical to throw out good tools to prove you can do something with bad ones.
Oh, I'm pretty much totally with you about the silliness of HTML5/JS/Canvas animations that keep popping up on HN. I agree that they all tend to run slow, use too much CPU, and take too much code to produce.
I don't think that's the right analogy. You're comparing tool with a technology. Adobe's tool already did all the hard part for you when you write for Flash. HTML5 can be the same too, once its tool matured enough.
Not to mention equivalent of this implementation in Flash would be equally complex. (No JS/No ActionScript.)
If that's true, then someone's ability to rewrite the tool is academic. And if it's academic, then this isn't impressive. My point is that it's impressive only in the sense that it rewrites the tools.
I can rewrite Adobe's tools in JS 1.5 and CSS3. I went a long way towards doing it - I wrote a whole platform. http://strikedisplay.blogspot.com. Mainly because I was scared of losing the tools I like to have around. But after gaining what I think is a pretty granular, deep understanding of which operations take longer in one or the other (pretty much everything takes longer in JS 1.5), and the trade-offs in other kinds of operations -- the only good thing about HTML5 is that you can force multithreading to suck up an even larger chunk of cycles, a fact that won't be lost on the porn/malware mafia.
have you ever seen flash run well on ARM? are you really comparing casual flash games that you have to pay for to casual obj-C sold through the appstore, a store that basically pays for itself and doesn't make much money?
and i love how you can just quash anything that demonstrates how HTML5, a nascent technology, is moving toward par with flash while not sending fans into overdrive and draining my battery. all to keep an ailing steve jobs happy.
Off topic: Do people really write games for iOS fully in Objective-C? Why not just stick to C++ for everything except the graphics (which would use the regular C OpenGLES API) and the bare minimum of Obj-C to interface with iOS (main game loop, etc)? You get a better language (IMO) and much easier portability.
http://www.apple.com/ipodnano/