Thursday, March 26th, 2009

Creating a clock in CSS

Category: CSS, Examples

<p>If you ever go to the BBC website you will see the working clock in the top right:

It thus seems appropriate that Paul Hayes of London has created an interesting experiment that shows how you can create an analogue clock using just CSS and JavaScript is only used to get the current time.

The real magic is in CSS transitions such as:

  1. /* -webkit-transition: property duration timing-function */
  2.  
  3. #clock img[src*='hour'] {
  4. -webkit-transform: rotate(90deg);
  5. }
  6.  
  7. #clock img[src*='second'] {
  8. -webkit-transition: -webkit-transform 60s linear;
  9. }
  10.  
  11. #clock:target img[src*='second'] {
  12. -webkit-transform: rotate(360deg);
  13. }

Nice work Paul!

Related Content:

15 Comments »

Comments feed TrackBack URI

“…create an analogue clock using just CSS and a WebKit-based browser…”

FTFY

Comment by MichaelThompson — March 26, 2009

Current Firefox beta supports -moz-transform as well. Not too sure a about a -moz-transition though

Comment by TNO — March 26, 2009

While this interesting and maybe a little bit cool, I think it is inappropriate for Webkit to take CSS (even if only for itself) in this direction. CSS was created to define style. This seems more like a behavior to me and that belongs to the Javascript problem space. Going down the the road that Webkit is going, the question is – where do you stop? Just how much do you extend CSS to be? I think you run the risk of creating solutions for problems that have already been solved.

Comment by Malic — March 26, 2009

@Mailc Are you advocating the creation of a whole new subset of Javascript that can be used to change how elements are displayed on the page? At the moment people use a combination of Javascript + CSS (or possibly Javascript + Canvas) to do this. If I can use CSS to change the color or opacity of an element, why can’t I use it to change the rotation of that element?

Comment by jeromew — March 26, 2009

@jeromew

I think maybe what malic was referring to was more along the lines of the transitions and related topics in the CSS proposals. Some of the proposed features seem to be more suitable as a programming task for Javascript. Things like the transitions feature. I have even seen suggestions of functions and variables being added into CSS.

CSS should be a style guide, not a programming language.

The transform is fine since that in essence is the style of the element. Rotation of an element can be considered similar to the color or opacity of an element. If it’s possible in print design then it should be possible in CSS design.

But transitions affect the behavior of the element.

Then again, we do have :hover so that can of worms has already been opened.

Comment by travisalmand — March 26, 2009

Or perhaps another question is how are CSS transitions supposed to play nice with SMIL?

Comment by TNO — March 26, 2009

I agree with Malic.

To me, it seems like Webkit is trying create CSS behaviors similar to what MS did with IE’s CSS Expressions close to a decade ago (which they have since abandoned in the most recent release of IE). I’m really hoping the W3C doesn’t add these behaviors to the CSS spec – behavior is much better suited to JS.

Comment by WillPeavy — March 26, 2009

I’m gonna have to side with Malic on this too. I thought the whole reason for CSS in the first place was separation of purpose, removing styling from content. Now we’re adding behavior into style? What happens when your CSS library and your javascript library start trying to do the same thing to the same element, or different things to the same element?

Comment by edthered — March 26, 2009

I think the webkit transforms and transitions are wonderful. Why should style be static? Not every use of these properties will be whizz-bang in your face flashkillers they will be subtle cues to the user. A smooth change in style to highlight an element needn’t be invoked by javascript, the js is there to tell the browser what what to do next not increment opacity between 0 and 1.

Comment by StuartJ — March 26, 2009

@jeromew

My thought wasn’t that CSS transformations are bad – on the contrary, rotations via CSS is crazy-delicious great. Bring it on, should have been there a long time ago! But my thought was that having time-of-day being something that could be part of a CSS selector was taking it too far.

Comment by Malic — March 26, 2009

Was going to say what everyone else already did. :P

Why is it bad when MS goes off in wild proprietary directions with CSS, but if Safari/Apple does it it’s newsworthy?

Comment by mdmadph — March 26, 2009

@Malic Ah, sorry – I must read things properly before commenting. I missed the blindingly obvious fact that it’s a *transition* and now I agree with you entirely :)

Comment by jeromew — March 26, 2009

@Malic I really have to disagree with you, why displaying time not in decimal but with a graphical interface that displays the same information should involve anything more than style ?

Isn’t style a way to display any structured data for a better human reading ? I do think this is a great way to use css : turn off css, you’ll have the time displayed in a numerical manner, turn it on, it is displayed in a graphicall manner, that’s just amazing !

Comment by temsa — March 27, 2009

@temsa

I believe the debate was over CSS controlling behavior and not how CSS displays data. Letting CSS parse data to affect how it changes the styling of the element seems really close to making CSS a programming language.

Although using CSS to graphical display data would be an interesting thing to play with, we can do that now with Javascript + CSS so why solve a problem that most people do not have? Plus I don’t feel like coding my CSS to do things for some browsers and then having to code Javascript for the other browsers that do not support the needed CSS features.

I for one want CSS to do CSS, Javascript to do Javascript, HTML to do HTML and ASP/PHP to do ASP/PHP. Once we start getting into overlap of these technologies it can only cause feature bloat, confusion and problems.

I want each tech to be lean and mean to do be the best at what it does and leave other tasks outside their areas for the tech designed to handle those tasks.

Comment by travisalmand — March 27, 2009

I believe the people yelling “this should not be in CSS” are missing an important point – which should be right up the Ajaxian alley. It doesn’t matter *where* this functionality is available, the big news is that it is built into the browser engine.

You can use these animations without touching CSS. You could make a pure-JS library to expose all these features. Sure, underneath it will be using the CSS OM, but all that will be hidden. After all, the current animation engines in JS already use the CSS OM to manipulate the document style as fast as possible. This approach is really no different.

But because this is built into the browser it will run faster, and can even be hardware accelerated like it is on the iPhone.

So, the people that want style in CSS and behavior in JS can do exactly that. Nothing has to change. Only now you have access to a much more powerful browser engine. I see this as a massive opportunity for taking web applications to the next level.

Comment by obscure — March 28, 2009

Leave a comment

You must be logged in to post a comment.