To this end, here are two experiments which do just that, one which places a mask over your face as you move and another that attempts to scale content based on your distance from the screen. Have a play below.

Mask overlay experiment

View experiment | GitHub

Scaling content experiment

View experiment | GitHub

Background

Back in 2009, when 3D transforms first appeared on the scene, and when I first toyed with a rotating 3D cube, I had the desire to make that object rotate based on the position of a viewer. As you look left, the cube might rotate left. At the time I’d seen some work with canvas processing video frames and detecting eye blinks. But I needed seamless access to the webcam, and that was only available through Flash.

In 2010, at Full Frontal, Paul Rouget reminded us of the possibilities of the webcam in the browser, but back then I didn’t make much of it. I needed a custom build of Firefox and that device API was eventually deprecated.

Fast forward to today and we have the getUserMedia (gUM) API, for accessing a user’s microphone(s) and webcam(s). This comes as part of the real time communications spec, and it’s supported, somewhat, in Chrome 21+ and Opera 12+, albeit in slightly different guises.

Face detection in canvas has also improved, and we have LiuLiu’s “not-so-slow” face detection scripts (for those interested, the technique in JavaScript is explained on LiuLiu’s blog). What’s more, the venerable Wes Bos used this in video, last year, to great effect. Much of my experimentation has been based on this, and I’d urge you to have a read yourself.

Put it all together and what have you got? A webcam stream dumped into a video element, processed into a canvas element, and processed again to search for faces, in real time, in the browser, without plugins. Huzzah.

Detecting the presence and relative distance of a face is much simpler than the angle a user is looking. So for now, rather than rotating, I have settled on a simple scale: as you move forwards or backwards, the content adapts, transitioning and transforming as appropriate.

It’s never simple though. The face detection only works some of the time. With busy backgrounds or low light conditions the detection fails more often. Sometimes the wrong area is detected, which can lead to radical and jarring shifts in the scale. Perhaps a rolling average would be a better indication, alas I haven’t built that.

How to

Below I have dissected the key parts of the experiments. And as always the experiment code is available on GitHub.

getUserMedia

Presently (Nov 2012) Chrome 21+ and Opera 12+ are the only browsers that support getUserMedia. Some early versions accepted a comma separated string of media types, e.g. “video, audio”, later versions use an object instead, {video: true}. In Chrome getUserMedia is name-spaced, as is window.URL, which we need for interpreting the webcam stream.

Before we begin it’s best to normalise this stuff. This gist and its comments were helpful, as was HTML5 Doctor’s guidance.

//normalise window.URL
window.URL || (window.URL = window.webkitURL || window.msURL || window.oURL);

//normalise navigator.getUserMedia
navigator.getUserMedia || (navigator.getUserMedia = navigator.webkitGetUserMedia || navigator.mozGetUserMedia || navigator.msGetUserMedia);

Now let’s call it:

// toString for the older implementation (found by https://github.com/agektmr)
var options = {video: true, toString: function(){ return "video"; }};
navigator.getUserMedia(options, successCallback, errorCallback);

Converting a stream to a video element

To show a webcam stream in a video element we need only set the video source to the stream returned by getUserMedia in the success callback. This is done either directly or using a URL object of that stream:

// using the normalised window.URL
function successCallback(stream) {
    video.src = (window.URL && window.URL.createObjectURL) ? window.URL.createObjectURL(stream) : stream;
}

Transplanting to canvas

For the video to render within canvas we need to take the current video frame and apply it to the canvas with drawImage. We need to do this as often as possible. A timer that calls the same function again after 50ms works well enough.

function drawFrame() {
    var canvas = document.querySelector('canvas'),
        context = canvas.getContext('2d');

    context.drawImage(video, 0, 0, canvas.width, canvas.height);
    setTimeout(drawFrame, 50);
}

Face detection

First we include the wonderful CCV library (ccv.js) and another file which defines a face object (face.js). To detect the faces in our canvas we simply call the detect_objects method and pass in our canvas:

ccv.detect_objects({canvas : (ccv.pre(canvas)), cascade: cascade, interval: 2, min_neighbors: 1});

This gives an array of detected objects, each with x and y co-ordinates, a width and a height. It looks a bit like:

{
    confidence: 0.16752329000000035,
    height: 48.500000000000014,
    neighbors: 1,
    width: 48.500000000000014,
    x: 80.50000000000001,
    y: 104.50000000000003
}

This operation is relatively slow. To speed up the face detection I recommend using a small canvas (200x160) and hence a scaled down video frame. This gives the algorithm much less data to assess and reduces processing time per frame from ~500ms to a more manageable ~100ms. The algorithm can also detect multiple faces, by default the scaling experiment uses the first found face, and only begins when there is only one face on screen. (The masks work for everyone).

To highlight the face or draw a mask over it:

// highlight
context.fillRect(face.x, face.y, face.width, face.height);

// mask
context.drawImage(mask, face.x, face.y, face.width, face.height);

Face size

When starting the webcam an initial face size is stored and used as a reference point for all future scaling. Comparing the current face’s height and the original face’s height we get a simple scale factor that we can apply directly as a transform on an element. This can be transitioned, if your computer can take that, at the same time as doing the video processing and face detection.

We need a way of testing media query rules in JavaScript, and a way of generating events when a new rule matches. There’s a specification for exactly this: there’s matchMedia to see if a query matches, and MediaQueryList with MediaQueryListeners to detect and respond to changes.

matchMedia has support in Chrome, Firefox 6+ and Safari 5.1+ and there’s even a polyfill (by Scott Jehl, Paul Irish, Nicholas Zakas) for other browsers. So we can happily perform our one off tests in JavaScript (probably on page load):

if (matchMedia('only screen and (max-width: 480px)').matches) {
  // iphone specific JS
}

However media query list listeners (that’s a mouthful) are only supported in Firefox 6+. This is the magic of firing events when something changes, it completes the circle.

All is not lost, there is another way of using CSS to generate events and that’s through CSS transitions. When a CSS transition ends it fires a transitionEnd event (webkitTransitionEnd, oTransitionEnd, transitionend) on the appropriate element. Now consider a transition that occurs only when a media query is applied. Hey presto, we have a JavaScript event triggered by media query rules, however complicated or convoluted that rule may be. This rocks and can form the basis of a MediaQueryList polyfill.

Simple transition CSS and event listener

.mq {
-webkit-transition: width 0.001ms;
-moz-transition: width 0.001ms;
-o-transition: width 0.001ms;
transition: width 0.001ms;
width: 0;
}

@media all and (max-width: 480px) {
.mq {
width: 1px;
}
}

var mq = document.querySelectorAll('.mq')[0],		
mq.addEventListener('webkitTransitionEnd', function() {
	/* Transition ends, media query matched */
}, false);

Proof of concept

I’ve taken the excellent matchMedia polyfill and quickly hacked together a version that includes transition events and a callback.

Proof of concept demo
(and on Github)

mql('all and (max-width: 700px)', callback);

Pass in a media query string and callback. It immediately returns the test result and the callback will fire whenever the test result changes, the only argument being the MediaQueryList object. This isn’t a polyfill because it doesn’t yet match the specification, if it did the originally returned MQL object would have addListener and removeListener functions (that’s a work in progress).

The CSS transitions are instantaneous via a duration of a little larger than 0, I’ve chosen 0.001ms.

Element transitions are bidirectional, so the event fires when the rule matches and when it no longer matches. Every time the event fires a test is performed to determine state, this is easy using matchMedia.

The CSS transition event tells us which element triggered the transition but no details about the media query rules that governed it. So we use unique elements for each rule to connect the dots.

.mq {
-webkit-transition: width 0.001ms;
-moz-transition: width 0.001ms;
-o-transition: width 0.001ms;
transition: width 0.001ms;
width: 0;
}

mql = (function(doc, undefined){

  var bool,
      docElem  = doc.documentElement,
      refNode  = docElem.firstElementChild || docElem.firstChild,
      idCounter = 0;

  return function(q, cb){
	
	var id = 'mql-' + idCounter++,
	    callback = function() {
		cb({ matches: (div.offsetWidth == 42), media: q });
	    },
	    div = doc.createElement('div');
	
	div.className = 'mq';
	div.style.cssText = "position:absolute;top:-100em";
	div.id = id;
        div.innerHTML = '&shy;<style media="'+q+'"> #'+id+' { width: 42px; }</style>';

	div.addEventListener('webkitTransitionEnd', callback, false);
	div.addEventListener('transitionend', callback, false); //Firefox
	div.addEventListener('oTransitionEnd', callback, false); //Opera

        docElem.insertBefore(div, refNode);
        //don't delete the div, we need to listen to events
        return { matches: div.offsetWidth == 42, media: q };
  };

})(document);

Demo code

$(function() {

    var $dynamic = $('.dynamic');
    mql('all and (max-width: 700px)', change);
    mql('all and (max-width: 500px)', change);
    mql('all and (min-width: 1200px)', change);

    function change(mql) {
        console.log(mql);
        $dynamic.prepend('<p>' + mql.media + ' &mdash; ' + mql.matches + '</p>');
    }
});

Support

Obviously for this to work we need both CSS transitions and media query support in the browser. Looking at caniuse.com and QuirksMode this technique should be supported by: Chrome, Android (2.1+), Opera (10.6+), Opera Mobile (10.0+), Firefox (4+), Safari (3.2+) and iOS (3.2+). Samsung’s Dolfin and Blackberry 6 support CSS animations, I presume that means transitions too, but I can’t easily test.

Of course, IE is lagging behind, as always. IE9 supports media queries but it has no transition support, that’s coming in IE10.

All references to the :target pseudo-selector have been removed, instead an “active” class is toggled using JavaScript. The CSS modal still uses an opacity transition but pointer events are gone. The default is now display:none with an intermediate state that renders the modal as display:block (remember it still begins at opacity: 0).

The flow is:

• Add an intermediate class to trigger the modal elements above everything, with opacity 0.
• Add an active class to trigger animation and transition to full opacity.
• On close, remove active class, add minimise class to trigger minimise animation and transition to opacity 0.
• Remove intermediate class.

Onclick handlers are added to the “post comment” links to add classes and to the close link to remove them. When opened a handler is added to the body to listen for the ESC key, which closes the modal. The first input in the modal is focused on open.

I took the opportunity to play with some HTML5 features. The comment form now uses placeholder attributes, and if supported, labels are hidden. The feature detection is delightfully simple:

supportPlaceholder: function() {
	  var i = document.createElement('input');
	  return 'placeholder' in i;
}()

See Dive into HTML5 for more.

The close link text which has an :after pseudo-element (i.e. the X) is no longer hidden, instead it becomes the cancel link and is essential for browsers that can’t comprehend generated content.

In webkit you’ll see the modal bounce in and minimise out (smoothly in Safari and iOS). In Firefox you’ll get an opacity transition and in IE the modal will just appear or disappear. In IE8 and below the page is not greyed out due to lack of rgba support. I’m fine with this. This is still a bit of a trial to see how people actually use the modal and what problems it might throw up.

In conclusion, with JavaScript much of the mechanical new CSS can be dropped and with a slightly more complicated class toggle system we achieve cross browser support, without sacrificing that lovely hardware accelerated CSS animation.

Still want that animation cross browser? I recommend looking into Faruk Ateş’s Runloop jQuery plugin which gives you keyframed animations in any browser.

In other news, I’ve tidied up the comments layout a little and added a short books category with a selection of books I highly recommend.

CSS Modal Experiment

In this experiment, clicking an ‘open’ link pops up a dialogue with a smooth hardware accelerated bounce (where supported). When open all other elements on the page are non-clickable. Closing the modal is also animated, with a minimise effect. I’ve marked up the modal using <aside>, but depending on the purpose of yours, <nav> or probably <details> might be more appropriate.

Of course, using images and JS will only make the modal better, and something like hitting ESC to close will never be reproduced in CSS. Pure CSS is rarely the best production-ready solution.

How to

The :target pseudo-selector changes the style of a targeted element. Combining a link pointing to an element with :target and altering visibility/display/opacity gives a hide/show mechanism. To facilitate the animations, which were jerky when using display:none, I’ve used a combination of :target, opacity and pointer events:

.modal {
opacity: 0;
pointer-events: none;
}

.modal:target {
opacity: 1;
pointer-events: auto;
}

The modal is two parts, one part container, one part content. Ideally the container would be generated using a pseudo-element, but I haven’t got that working yet. The container spreads across the whole page and dims the background with rgba. A high z-index puts the modal on top.

.modal {
position: fixed;
top: 0;
left: 0;
right: 0;
bottom: 0;
background: rgba(0,0,0,0.5);
z-index: 10000;
…
}

The content is positioned roughly in the middle and is prettified with a sprinkling of text shadow, border radius, box shadow and gradient.

There are two animations, one named “bounce” (scale to slightly larger than normal, then fall back) and another, “minimise”, which act on the content part. These combine with a separate opacity transition on the container.

The simple opacity transition:

.modal {
…
-webkit-transition: opacity 500ms ease-in;
-moz-transition: opacity 500ms ease-in;
transition: opacity 500ms ease-in;
}

The scaling animations, although only 2D, uses scale3d for hardware acceleration. To make the bounce more realistic box shadow is also animated, which comes with a performance hit. Showing only the webkit version for brevity:

@-webkit-keyframes bounce {
  0% {
  	-webkit-transform: scale3d(0.1,0.1,1);
  	box-shadow: 0 3px 20px rgba(0,0,0,0.9);
  }
  55% {
  	-webkit-transform: scale3d(1.08,1.08,1);
  	box-shadow: 0 10px 20px rgba(0,0,0,0);
  }
  75% {
  	-webkit-transform: scale3d(0.95,0.95,1);
  	-box-shadow: 0 0 20px rgba(0,0,0,0.9);
  }
  100% {
  	-webkit-transform: scale3d(1,1,1);
  	box-shadow: 0 3px 20px rgba(0,0,0,0.9);
  }
}

@-webkit-keyframes minimise {
  0% {
  	-webkit-transform: scale3d(1,1,1);
  }
  100% {
  	-webkit-transform: scale3d(0.1,0.1,1);
  }
}

To change the animation on open we can use the cascade and override the default animation with a more specific one, using :target again:

.modal > div {
…
-webkit-animation: minimise 500ms linear;
}

.modal:target > div {
-webkit-animation-name: bounce;
}

The close button is a hidden close link with a styled ::after pseudo-element that scales on hover/focus/active. As we’re hiding the original close link, there are some hoops to jump through to make the :focus state change on the pseudo-element. The traditional clip, text indent or visibility hidden methods all fail, and I’ve resorted to color:transparent and some specific focus styles to override the confused native ones.

.modal a[href="#close"] {
…
color: transparent;
}

.modal a[href="#close"]:after {
content: 'X';
display: block;
…
}

.modal a[href="#close"]:focus:after,
.modal a[href="#close"]:hover:after {
-webkit-transform: scale(1.1,1.1);
-moz-transform: scale(1.1,1.1);
}

.modal a[href="#close"]:focus:after {
outline: 1px solid #000;
}

Caveats

It won’t work in IE8 and below, there’s no pointer-event support and opacity is poorly implemented. IE9 supports :target but no pointer-events. Some IE specific styles could easily switch the opacity toggle to a display or visibility one.

Users will still be able to tab through the links in the background and activate them. This only becomes an issue if you ignore the focus state…

As I alluded to at the start, some JS hooks for keyboard interaction wouldn’t go amiss, ESC to close and something to pull focus to the current modal and then back again on close.

The close button would probably look better with an image and the markup uses an extra containing element, which is always undesirable.

Animations can be great, in small quantities, but something that animates too much and gets in the way of functionality is a major drawback for users. It would be quite easy to go overboard with this.

3D CSS Sphere
Works in the latest Safari and iOS (just about runs on an iPhone 4).

Recently I’ve been looking at creating applicable 3D carousels. These rely on positioning panels in a circle around a central point (ie. rotation about the Y-axis), I put these panels in an unordered list. A natural extension is to duplicate each <ul> and rotate about the X-axis. With ‘A’ rounds (or lists), and ‘B’ panels per round (<li>s), I built a script that would distribute these in a circular manner, panels about Y-axis, lists about the X-axis, creating a sphere.

The more elements per round and the more rounds, the smoother the sphere. But this soon stacks up and kills Safari. The optimum numbers have been about 9 rounds and 30 panels per round for a decent looking sphere, but that’s 279 3D elements and Safari starts to choke. Allowing the panels to overlap eases this somewhat and leads to a tighter sphere but it still appears blocky.

The biggest gains come with border radius. Using a huge radius that made each panel circular the sphere suddenly gained a lovely curvature, and the number of rounds and panels could be reduced. In the experiment I use 8 rounds and 24 panels (200 elements). This doesn’t start choking until I start aggressively animating.

Playing with this I’ve built a few different styles of sphere. In the experiment I’ve included the blocky “square” version, along with the smoothed out border radius one (default). Marking panels white, and a few black can create a nice eye-ball effect.

Also included in the experiment are versions showing a single round and another style named “contact”. This takes two lists and animates them like the space transportation device in the Jodie Foster movie of the same name.

Animating the border radius on all 192 panels (if your machine can cope), gives a neat kaleidoscope effect, also included in the experiment.

Code

The generated HTML is simply a couple of <div>s containing lists:

<div id="sphere">
	<div class="container">
		<ul>
			<li></li>
			<li></li>
			…
		</ul>
		…
	</div>
</div>

To transform each set of panels into a circle the total number is divided by 360 to get the angle of rotation. Merely rotating will put all panels on top of each other, translating in the Z axis will move them out from the centre point. The correct translation distance so the panels slightly overlap (i.e. the circle radius) is worked out with some simple trigonometry. Lists are rotated in the X axis, simply the number of lists divided by 360.

Looping through each panel for each list, the angles of rotation are gradually increased by the calculated increments and applied to the elements:

var panels = p || this.panels,
rounds = r || this.rounds,
rotationPerPanel = 360/panels,
rotationPerRound = 360/2/rounds,
yRotation, xRotation,
width = this.panelWidth,
zTranslate = (width/2) / Math.tan(rotationPerPanel * Math.PI/180),
$container = this.el,
$ul, $li, i, j;

this.el.html('');
for(i = 0; i < rounds; i++) {
	$ul = $('<ul>');
	xRotation = rotationPerRound * i;
	$ul[0].style[transformProperty] = "rotateX("+ xRotation + "deg)";
	for(j = 0; j < panels; j++) {
		$li = $('<li>');
		yRotation = rotationPerPanel * j;
		$li[0].style[transformProperty] = "rotateY("+ yRotation +"deg)
                         translateZ("+ zTranslate +"px)";
		$ul.append($li);
	}
	$container.append($ul);
}

To achieve the 3D effect we give #sphere some perspective, which forms the containing block. A second container transitions between different transforms, letting us rotate the sphere. The complicated transform parts are applied inline via the JavaScript above, but each list element needs preserve-3d so its direct descendants are transformed in the same 3D space (rather than in 2D).

#sphere {
width: 100px;
height: 100px;
margin: 200px auto;
-webkit-perspective: 800;
-moz-persective: 800;
}

.container {
width: 100px;
height: 100px;
-webkit-transition: -webkit-transform 200ms linear;
-webkit-transform-style: preserve-3d;

-moz-transition: -webkit-transform 200ms linear;
-moz-transform-style: preserve-3d;
}

.container > ul {
-webkit-transform-style: preserve-3d;
-moz-transform-style: preserve-3d;
width: 100%;
height: 100%;
position: absolute;
}

.container li {
width: 98px;
height: 98px;
position: absolute;
display: block;
background: #000;
border: 1px solid #fff;
opacity: 0.1;
border-radius: 50px;
}

This article is a brain dump from last night’s event.

CSS3 media queries let us adapt CSS rules to different viewport properties; width, height, pixel ratio, even colour and monochrome screens (full list). Aside: the Amazon Kindle (which uses webkit) reports itself as colour, with 8 levels, rather than monochrome.

The common process is to design for the desktop and use media queries to adapt downwards. On thinner devices content is linearised, navigation moves to the top or bottom, less important elements are sometimes hidden; everything is simplified down to the page’s core use case.

A number of tutorials have offered up the exact pixel-based media queries needed to target specific devices, a sort of restricted browser sniffing. This isn’t truly progressive, you can never cover all devices, and devices change, revisiting code for device iterations isn’t going to be fun.

Media queries don’t need to be pixel based either, changing a page layout based on ems will adapt content for larger text sizes. If the user’s text size is huge, our viewport is the same but we’ve got less space to play with, a linear mobile-like design might be more desirable.

This act of adapting downwards works for devices like the iPhone and iPad, but what about those that don’t support media queries? They’re going to get the full desktop version and it’s not going to be pretty.

Luke Wroblewski has suggested designing for mobile first (an excellent read). In terms of responsive enhancement that means creating your linear site as the baseline and building outwards around content, bringing in features as capabilities improve and constraints are relaxed. As the viewport widens, media queries can introduce columns, rather than remove them. It’s the same process but in the opposite direction.

All mobile devices and older browsers would get the simplified, linear design. This works on the assumption that desktop browsers support media queries, IE 8 and below do not, ergo they’ll be seeing the linear site design. This may be acceptable, but in the majority of cases IE will need some sort of hack to get the full featured version.

Using conditional IE comments an IE layout can be hacked in. The IE specific styles are likely to repeat existing code, undesirable, but unavoidable? This is still a one size fits all approach as IE will not adapt to screen or text size. For this we need a JS poly-fill, one that enables media queries in older browsers. There’s a library on Google Code that does just this, CSS3 Media Queries JS.

Building a page that can be linearised means putting the most important information first in the source code. This assumes that the context of “what is important” is similar on different devices. If the context is different, that makes a case for serving different content, usually via a standalone mobile site (which should always come with a link to the full version).

And on the topic of serving different content, there is also the speed problem. Hiding and showing parts of a page using CSS is great, but it doesn’t stop the slower mobile networks from downloading the unnecessary parts, including those huge background images. PPK has written an excellent article on combining media queries and javascript to avoid some of these caveats.

To round this brain dump off, I’ll recommend some other articles on the subject, which go into some of the technical aspects in a little more depth.

Ethan Marcotte’s “Responsive Web Design“
Jeremy Keith’s “Responsive Enhancement“
Yiibu’s “Rethinking the mobile web“
PPK’s “State of Mobile Web Development”

CSS pyramid — proof of concept
For now this only works in Safari 5.0.2+ and iOS, although 3D transforms will surface in Firefox 4 and the next build of Chrome. The demo doesn’t use JavaScript.

Combining squares and triangles, cubes and pyramids, all sorts of 3D structures are now possible, if you are so inclined. Not necessarily useful, but possible.

The rotation is performed using a -webkit-animation, I’ve given the animation the name “spin”, which rotates the pyramid around Y from 0 to 360 degrees:

#pyramid {
-webkit-animation: spin 5s linear infinite;
-moz-animation: spin 5s linear infinite;
}

@-webkit-keyframes spin {
  from {
  	-webkit-transform: rotateY(0deg) rotateX(-20deg);
  }
  to {
  	-webkit-transform: rotateY(360deg) rotateX(-20deg);
  }
}

@-moz-keyframes spin {
  from {
  	-moz-transform: rotateY(0deg) rotateX(-20deg);
  }
  to {
  	-moz-transform: rotateY(360deg) rotateX(-20deg);
  }
}

If you haven’t seen it before, the code to create an approximate equilateral triangle is as follows:

#pyramid > div {
position: absolute;
border-color: transparent transparent transparent rgba(50, 50, 50, 0.5);
border-style: solid; 
border-radius: 3px;
border-width: 200px 0 200px 346px;
}

Tantek Çelik coined this technique in his study of regular polygons which includes pentagons, hexagons and octagons. The methods are explained over at the Filament Group.

The 3D techniques I’ve used in this experiment are explained in my 3D cube post (July 2009). This is a proof of concept and I haven’t delved into the mathematics or geometry too much, instead opting for the slightly faster but significantly less clever and less reproducible trial-and-error approach.

#pyramid > div:first-child  {
-webkit-transform: rotateY(-19.5deg);
-moz-transform: rotateY(-19.5deg);
}

#pyramid > div:nth-child(2) {
-webkit-transform: rotateY(90deg) rotateZ(60deg);
-moz-transform: rotateY(90deg) rotateZ(60deg);
}

#pyramid > div:nth-child(3) {
-webkit-transform: rotateX(60deg) rotateY(19.5deg);
-moz-transform: rotateX(60deg) rotateY(19.5deg);
}

#pyramid > div:nth-child(4) {
-webkit-transform: rotateX(-60deg) rotateY(19.5deg) translateX(-116px) translateY(-200px);
-webkit-transform-origin: 0 0 -326px;

-moz-transform: rotateX(-60deg) rotateY(19.5deg) translateX(-116px) translateY(-200px);
-moz-transform-origin: 0 0 -326px;
}

Experiment: 3D cube with touch gestures and click and drag
One year on and the cube still only works in Safari. Chrome, which says it supports webkit-perspective and webkit-transform, still renders differently. Firefox doesn’t support 3D transforms yet.

It works relatively simply: on click the start co-ordinates are saved and on drag the difference between current drag position and starting co-ordinates are applied to the cube as a transform, which is completed after the specified transition duration. Many thanks to Remy Sharp and his rubik’s experiment, which got me started with a lot of the basics.

Touch tweaks

Pixel values for touch positions are found in event.originalEvent.touches[0].pageX, instead of event.pageX. Using ‘start minus current’ pixel values led the cube to rotate more than intended on the iPhone. To correct, and for intuitive behaviour, the difference is reduced by a factor of four.

JavaScript prevents single touch default events — e.g. scrolling and text selection, but if it detects more than one touch (event.originalEvent.touches.length) the cube won’t rotate, so pinch and zoom will still work. This is a compromise.

A 200ms transition duration suits the browser, but on touch devices it felt sluggish, so I’ve upped it to 50ms so the cube is always at your finger-tips.

Better CSS

The cube is created exactly as before, but I’ve simplified the markup a little — dropping the face and number class names in favour of CSS3 selectors:

#cube > div:first-child  {
-webkit-transform: rotateX(90deg) translateZ(200px);
-moz-transform: rotateX(90deg) translateZ(200px);
}

#cube > div:nth-child(2) {
-webkit-transform: translateZ(200px);
-moz-transform: translateZ(200px);
}

#cube > div:nth-child(3) {
-webkit-transform: rotateY(90deg) translateZ(200px);
-moz-transform: rotateY(90deg) translateZ(200px);
text-align: center;
}

#cube > div:nth-child(4) {
-webkit-transform: rotateY(180deg) translateZ(200px);
-moz-transform: rotateY(180deg) translateZ(200px);
}

#cube > div:nth-child(5) {
-webkit-transform: rotateY(-90deg) translateZ(200px);
-moz-transform: rotateY(-90deg) translateZ(200px);
}

#cube > div:nth-child(6) {
-webkit-transform: rotateX(-90deg) rotate(180deg) translateZ(200px);
-moz-transform: rotateX(-90deg) rotate(180deg) translateZ(200px);
}

Any questions?

This is quite a speedy write-up, if anything needs explaining I’m happy to go into a bit more detail.

Reset input type search

Safari renders search inputs with curved corners and a spy glass. If this doesn’t fit into your design, but you want to retain correct semantics, this reset is helpful. The first line removes the curved corners, but leaves a white space where the spy glass was, this is removed using the second line.

input[type=search] { 
-webkit-appearance: none;
}
input[type=search]::-webkit-search-decoration {
display: none;
}

Border radius

Both Safari 5 and the latest Chrome support border-radius, given the fast update curves for these browsers, I have stopped using -webkit-border-radius, and almost always default to the useful shorthand (older versions of iOS are a known caveat).

border-radius: 10px 0 0 10px;

Tweaked clearfix

I still see a lot of sites using the old clearfix, including IE for Mac hacks. I’ve cleaned this up a bit and moved the IE specific parts into conditional IE stylesheets. For lists, I found I often need to clear each li, to save littering the HTML with class names, I added clearfixItems li, now I only need one class on the ul or ol.

.clearfix:after,
.clearfixItems li:after {
content: ".";
display: block;
height: 0;
clear: both;
visibility: hidden;
}

Then in IE6 and IE7:

.clearfix, .clearfixItems li {
zoom: 1;
}

Equal height columns

For when you want your containers to have the same height. If you are unfamiliar with this technique, I recommend reading Ed Eliot’s article.

.col {
margin-bottom: -1000px;
padding-bottom: 1000px;
}

Ligatures and kerning pairs

Where fonts support it, text rendering can be improved by enabling kerning pairs and ligature support. Add the following to your body to enable it on all text:

text-rendering: optimizeLegibility;

Firefox’s default state (text-rendering: auto) partially enables this, optimizing legibility on font sizes above 20px (surely legibility is most important on the smallest text?). Using the above code will optimize all font sizes, more details are available at MDC, as pointed out in the comments by rdela.

Gradients

An invaluable tool for avoiding images and extra HTTP requests. For the most part I avoid providing fallback images, instead seeing gradients as a progressive enhancement. This usually means Opera and FF3.5 or less will see a solid colour, I’m fine with that.

background: #990000;
/* old: background: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#cc0000), to(#990000)); */
background: -webkit-linear-gradient(#cc0000, #990000);
background: -moz-linear-gradient(#cc0000,#990000);

And in IE conditional stylesheets:

filter: progid:DXImageTransform.Microsoft.gradient(startColorstr=#cc0000, endColorstr=#990000);

Inevitably coming back to “FofR Online” after such a long period I wasn’t happy with the site, and I’ve committed the web faux pas of changing the design and the domain name at the same time. I’ve dropped the rather meaningless “FofR Online” pseudonym in favour of using my name as a brand. All pages now redirect to paulrhayes.com.

This site is my first experiment with TypeKit and web fonts. I’ve chosen to use Museo for headers and Swing dancer for my name. I can’t say I’m entirely happy, but if I waited for that I’d never release anything.

Since working on the 3D cube using 2D transforms back in April I’ve experimented with perspective to create something more powerful, playing around with 3D transforms on the iPhone a few times (e.g. this early rotating demo). Now I’ve got something worth sharing.

A 3D cube can be created solely in CSS, with all six faces. Using JavaScript to detect key presses and update inline styles this cube can be intuitively navigated.

Result

A 3D cube that rotates using the Up, Down, Left and Right arrow keys.
Supported browsers: WebKit Nightly r46042+

How To

I’ll start with the markup, because it’s simple. Each of the six cube faces is given a face class and another relating to it’s number. These six faces sit within a cube container, which sits in another wrapper, each is necessary.

<div id="experiment">
	<div id="cube">
		<div class="face one">
			One face
		</div>
		<div class="face two">
			Up, down, left, right
		</div>
		<div class="face three">
			Lorem ipsum.
		</div>
		<div class="face four">
			New forms of navigation are fun.
		</div>
		<div class="face five">
			Rotating 3D cube
		</div>
		<div class="face six">
			More content
		</div>
	</div>
</div>

The outer wrapper serves as a camera, on which you apply some perspective — appropriate 3D transformations are then applied to descendants. -webkit-perspective defines the depth of the Z-plane and relative sizes of elements above and below it, -webkit-perspective-origin specifies the perspective’s origin. View a perspective example (webkit.org)

    #experiment {
      -webkit-perspective: 800;
      -webkit-perspective-origin: 50% 200px;
    }

The second container, the actual cube, has a specified height, margin, position, etc. as usual. The height and width are necessary to create some confines for the cube face transformations — alternatively the width defaults to 100% and the cube’s appearance would vary with window width. -webkit-transition (documentation) defines the animated property, duration and timing-function — we’re animating the 3d transformation (via -webkit-transform) linearly for two seconds. -webkit-transform-style determines whether child elements lie flat against their parent (“flat”) or remain in 3D space (“preserve-3d”).

    #cube {
      position: relative;
      margin: 0 auto;
      height: 400px;
      width: 400px;
      -webkit-transition: -webkit-transform 2s linear;
      -webkit-transform-style: preserve-3d;
    }

Using the .face class common styles are applied to the six sides; coloring, size, padding, etc. Importantly they are each positioned absolutely, relative to the cube container. The background rgba property is included to make the cube look pretty and transparent.

    .face {
      position: absolute;
      height: 360px;
      width: 360px;
      padding: 20px;
      background-color: rgba(50, 50, 50, 0.7);
    }

Each of the faces, one through six, needs to be rotated in 3D space to its correct starting position. Using translateZ the elements are brought 200px (half their width) off the Z-plane. Each of the faces must be at 90 degrees. Rotating solely in the X plane positions the top and bottom faces (one, six), before rotating the last four faces in the Y plane, much like origami. The extra rotate on the sixth face rotates the content in 2D space to correct its orientation.

    #cube .one  {
      -webkit-transform: rotateX(90deg) translateZ(200px);
    }

    #cube .two {
      -webkit-transform: translateZ(200px);
    }

    #cube .three {
      -webkit-transform: rotateY(90deg) translateZ(200px);
    }

    #cube .four {
      -webkit-transform: rotateY(180deg) translateZ(200px);
    }

    #cube .five {
      -webkit-transform: rotateY(-90deg) translateZ(200px);
    }

    #cube .six {
      -webkit-transform: rotateX(-90deg) translateZ(200px) rotate(180deg);
    }

Our cube is now complete — but it doesn’t move! With a keydown event listener we can increment X and Y angles based on different key presses, before applying them as inline styles on the cube container. In combination with the transition effect on #cube, all six faces rotate in sync from their original position to the newly defined angle, creating a seamless 3D cube interface.

  	var xAngle = 0, yAngle = 0;
	document.addEventListener('keydown', function(e)
	{
		switch(e.keyCode)
		{

			case 37: // left
				yAngle -= 90;
				break;

			case 38: // up
				xAngle += 90;
				break;

			case 39: // right
				yAngle += 90;
				break;

			case 40: // down
				xAngle -= 90;
				break;
		};

		$('cube').style.webkitTransform = "rotateX("+xAngle+"deg) rotateY("+yAngle+"deg)";
	}, false);

Result

CSS3 Accordion
Works in browsers that support the :target pseudo-class, see the Quirks Mode compatibility tables. Animation works in recent WebKit based browsers.

How To

Each part of the accordion has an ID, heading and content region. The header includes a link that matches the section’s ID, whilst the content is wrapped in a container which will control its display.

<div class="accordion">
	<h2>Accordion Demo</h2>
	<div id="one" class="section">
		<h3>
			<a href="#one">Heading 1</a>
		</h3>
		<div>
			<p>Content</p>
		</div>
	</div>
	<div id="two" class="section">
		<h3>
			<a href="#two">Heading 2</a>
		</h3>
		<div>
			<p>Content</p>
		</div>
	</div>
</div>

The CSS then relies on the :target pseudo-class to apply different styles to the chosen section — increasing the height and, in large content cases, altering the overflow behaviour to allow scrolling. To animate the opening and closing of sections the -webkit-transition property is needed (documentation), in this case acting on the height attribute for a duration of 0.3 seconds using the ease-in timing function.

Stripping out the styling, the CSS boils down to:

.accordion h3 + div {
	height: 0;
	overflow: hidden;
	-webkit-transition: height 0.3s ease-in;
	-moz-transition: height 0.3s ease-in;
	-o-transition: height 0.3s ease-in;
	-ms-transition: height 0.3s ease-in;
	transition: height 0.3s ease-in;
}

.accordion :target h3 + div {
	height: 100px;
}

.accordion .section.large:target h3 + div {
	overflow: auto;
}

Critique

Obviously this approach has its limitations. Multiple open accordions on one page wouldn’t be possible — restricted by a URI’s one fragment identifier limit; as one accordion opens the other would lose the target and automatically close. Similarly, pages that use a fragment identifier for everyday use will notice oddities — take for instance when using top links to return to the top of the page, any accordion would, in this case, reset. Other uses include accessibility links and simulated page histories when using Ajax.

To enable IE6 and IE7 support for new HTML5 tags, which are not naturally styled, some JavaScript is necessary. As per the ‘shiv’ article, Remy Sharp has a small script that creates DOM elements, one for each type of new HTML5 tag, the simple act of doing so leads Internet Explorer to apply styles to said tags. I slightly modified the existing script to add the recently proposed hgroup.

Even though these tags accept style they don’t come with their default renderings. For that we need a bit of CSS to make block elements behave as they should.

(function(){
	if(!/*@cc_on!@*/0) return;
	var e = "abbr,article,aside,audio,bb,canvas,datagrid,datalist,details,dialog,
		eventsource,figure,footer,hgroup,header,mark,menu,meter,nav,output,
		progress,section,time,video".split(','),i=0,length=e.length;
	while(i<length){
		document.createElement(e[i++])
	}
})();

article, aside, dialog, footer, header, section, footer, nav, figure {
	display: block;
}

I’ve also updated the Eric Meyer reset script, removing now deprecated HTML 4 tags and applying reset to the new elements, so they do not unexpectedly inherit padding, margin, etc. in the future. These changes are not yet exhaustive.

Moving onto the page’s actual markup, the new DOCTYPE and character encoding settings are remarkably simple. Standards based web development is getting easier. For browsers that do not support HTML5, the new DOCTYPE still triggers standards mode. The xmlns HTML attribute is no longer necessary and the profile attribute has been dropped.

<!DOCTYPE html>
<html lang="en" dir="ltr">
<head>
	<meta charset="UTF-8" />
	<title>FofR Online</title>

The header section has been placed in the appropriate <header> tags, and similarly with the footer. I’d hoped to include the ‘About Me’ section within this, but as part of the specification you cannot include headings within a <footer> element.

Each of the posts comes wrapped in an <article> tag, i.e. an independent element with content that could standalone. Within are the respective <header> (containing title and date) and <footer> (containing meta links) elements. Technically the meta links could be marked as <nav>, but the former is more fitting and still acceptable use.

The date makes use of HTML5’s <time> element, with a datetime attribute that gives the precise posting time, including timezone offset.

The previous and next links that follow the article can comfortably sit within a <nav> tag. Similarly, my sidebar region is predominantly navigation based with lists of archives and categories, it’s been marked as such.

<article id="post-67" class="">
	<header>
		<h2 class="entry-title"><a href="" title="" rel="bookmark">POST TITLE</a></h2>
		<div class="entry-date">
			<time datetime="2009-04-30T15:54:28-07:00" class="published" title="2009-04-30T15:54:28-07:00">April 30, 2009 &#8211; 3:54 pm</time>
		</div>
	</header>
	<div class="entry-content">
		POST
	</div>
	<footer class="entry-meta">
		META LINKS
	</footer>
</article>

<nav id="nav-below" class="navigation clearfix">
	<div class="nav-previous"></div>
	<div class="nav-next"></div>
</nav>

One avenue I should explore is the inclusion of the <section> tag, which I’d like to break up individual posts, probably by splitting the content at level three headings downwards; thereby becoming the header of each new section.

It’ll be a while before the real benefits of HTML5 can be fully appreciated by everyone, but it feels good to make a start, however small that step may be.

To demonstrate the power of this effect a second experiment with multiple cubes and proprietary WebKit transitions is also available.

Results

A 3D cube created with CSS
Supported browsers: Safari 3.2+, Google Chrome, Firefox 3.5+

Experiment with multiple cubes and CSS transitions, still no JavaScript
Supported browsers: Safari 4+, Google Chrome

How To

Similar to my previous experiments, the HTML markup is very simple. Each of the faces has its own DIV, class and content. The top face requires some extra markup to aid the transformation, more on that shortly.

<div class="cube">
	<div class="topFace">
		<div>
			Content
		</div>
	</div>
	<div class="leftFace">
		Content
	</div>
	<div class="rightFace">
		Content
	</div>
</div>

A short disclaimer, the geometry in this example is ‘fudged’, in that the values have been adjusted to appear roughly correct. I know that the dimensions are slightly out of whack, this is merely to save my head from mathematics and to get the concept out there quickly for people to see. With that said, let’s crack on with the CSS.

Each of the three rectangles is given a slightly different shade of gray to give the impression of depth, in this example the left face is in shadow. The faces are each positioned absolutely, relative to the cube container. Each face is 200 x 200 pixels, including 10 pixels of padding.

.cube {
	position: relative;
	top: 200px;
}

.rightFace,
.leftFace,
.topFace div {
	padding: 10px;
	width: 180px;
	height: 180px;
}

.rightFace,
.leftFace,
.topFace {
	position: absolute;
}

Now for the fun bit. The left and right rectangles are skewed by ±30˚ along the vertical axis, with the right face shifted left by 200px, cleanly lining up the two edges to create a corner that is center aligned.

.leftFace {
	-webkit-transform: skewY(30deg);
	-moz-transform: skewY(30deg);
	background-color: #ccc;
}

.rightFace {
	-webkit-transform: skewY(-30deg);
	-moz-transform: skewY(-30deg);
	background-color: #ddd;
	left: 200px;
}

The top face proves more problematic; it needs to be skewed, scaled, rotated and positioned. The skew is the same, –30˚ along the vertical axis, this skewed rectangle must then be rotated clockwise by 60˚. Rotating the rectangle itself leads to a change in orientation of its content, a container must be added and then rotated.

A simple way of creating a top face without resorting to maths is to duplicate the left and right rectangles, skew them in the opposite directions (by inverting the sign, e.g. left face is now skewed by –30˚) and position them against the existing faces to create a diamond shape between the two sets. Now use positioning and scaling to fill this diamond and form the top face, deleting the duplicates when finished. My results led to a scaling factor of 1.16 in the Y direction which I have accounted for by reducing the font-size by the same factor.

.topFace div {
	-webkit-transform: skewY(-30deg) scaleY(1.16);
	-moz-transform: skewY(-30deg) scaleY(1.16);
	background-color: #eee;
	font-size: 0.862em;
}

.topFace {
	-webkit-transform: rotate(60deg);
	-moz-transform: rotate(60deg);
	top: -158px;
	left: 100px;
}

The final CSS looks like this:

.cube {
	position: relative;
	top: 200px;
}

.rightFace,
.leftFace,
.topFace div {
	padding: 10px;
	width: 180px;
	height: 180px;
}

.rightFace,
.leftFace,
.topFace {
	position: absolute;
}

.leftFace {
	-webkit-transform: skewY(30deg);
	-moz-transform: skewY(30deg);
	background-color: #ccc;
}

.rightFace {
	-webkit-transform: skewY(-30deg);
	-moz-transform: skewY(-30deg);
	background-color: #ddd;
	left: 200px;
}

.topFace div {
	-webkit-transform: skewY(-30deg) scaleY(1.16);
	-moz-transform: skewY(-30deg) scaleY(1.16);
	background-color: #eee;
	font-size: 0.862em;
}

.topFace {
	-webkit-transform: rotate(60deg);
	-moz-transform: rotate(60deg);
	top: -158px;
	left: 100px;
}

Result

Experiment: Auto-scrolling CSS3 Parallax Effect
Experiment works in Safari 4 Beta and Google Chrome. No JavaScript necessary.

How To

The HTML markup is fairly simple, one DIV for the background and another for the content, the example uses CSS3’s multiple backgrounds, so no need for extra markup to accommodate all those other images:

<div id="background"></div>
<div id="content">
	Content
</div>

For the CSS the background container is set to a fixed position (for convenience more than anything) and spread across the bottom of the page using the top, left, bottom and right properties. The background images are defined using the background shorthand property with multiple declarations being comma delimited, the first being the top-most. Each of the images has a different position defined in percentage, so as the size of the container changes (e.g. on window resize) the images move disproportionately to each other; creating the impressive parallax effect.

#background {
	background: url('../images/foreground.png') 5% 5%,
		url('../images/midground.png') 20% 20%,
		url('../images/background.png') 90% 110%;
}

Ordinarily this effect is only seen when the page is re-sized or JavaScript is used for animation. My first approach to animation via CSS was to apply the transition to the background-positions, with background-position being an animatable property as defined in the proposed specification. However this doesn’t yet work in the latest WebKit nightly build (r42142), it is a known bug.

As an alternate route, albeit a temporary one, I have opted to use transitions to animate the left-most edge of the background container (for instance from 0px to –100px). This gradually alters the overall width of the container causing the backgrounds to shift disproportionately as per their percentages, creating the parallax effect. With a large enough duration and left position the effect appears to be continuous.

#background {
	left: 0;
	-webkit-transition: left 300s linear;
}

#experiment:target #background {
	left: -5000px;
}

To make things a bit more fun I’ve increased the ‘flying speed’ when the mouse hovers over the background area. The final CSS looks like this:

#background {
	background: url('../images/foreground.png') 5% 5%,
		url('../images/midground.png') 20% 20%,
		url('../images/background.png') 90% 110%;
	top: 218px;
	left: 0;
	right: 0;
	bottom: 0;
	position: fixed;
	-webkit-transition: left 300s linear;
}

#experiment:target #background {
	left: -5000px;
}

#experiment:hover #background {
	left: -9999px;
}

This clock experiment does not advocate such use of style sheets, it is instead used to demonstrate the capabilities and possibilities of WebKit’s transform and transition properties. It has inadvertently highlighted the controversial and unexpected nature by which web developers may use them. Should this cross-pollination of behaviour definition become standard? Is it risky? What might the side effects be?

Comments on the Ajaxian post began the discussion, Malic opened the debate (this comment is particularly in reference to ‘transition’ rather than the more widely accepted ‘transform’):

While this [is] 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.

This yielded some opposition but the majority supported the notion, Travis Almand champions the new transform property but strongly questions its counter-part:

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

Before highlighting that the road to behaviour in CSS has already begun with the much used :hover, accompanied by :active, and :focus — user action pseudo-classes, agents sometimes change the rendering in response to user actions; response being the keyword.

Will Peavy comments that these behaviours wreak reek of IE’s abandoned CSS expressions, and edthered asks:

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?

John Dowdell of Adobe has also weighed in with an honest rant that I heartily recommend reading, even if I’m slightly jealous that I cannot articulate my prose as well.

The clock example shows that people will use technologies in unexpected ways. The creators of Usenet did not intend mass advertising. […] Stuffing the genie back inside the bottle is harder than looking carefully at the bottle before opening it.
[…]
We may not be able to persuasively articulate why this will eventually be considered a bad architectural decision. It’s like when vendors of email clients started talking about how wonderful it would be to add hidden graphics and scripting to the emails strangers send to you. Vague warnings of an unsound future are at a disadvantage to self-interested “But I wanna do it!!” evangelists.

It’s hard to persuasively document future risks. But encumbering HTML and CSS like this is not the way to bless your own multimedia engine.

Result

Experiment: CSS Analogue Clock
Experiment works in Safari 4 Beta and Google Chrome. A working clock that optionally resorts to JavaScript to grab the current time (can be achieved by other means).

How To

Before getting into the nitty gritty I created four images, a clock face and three transparent PNG hands (seconds, minutes and hours), ensuring that each of these were the same size so that when overlayed their centres would align. The HTML and CSS to get us going is as follows:

<div id="clock">
	<div id="hour"><img src="images/hourHand.png" /></div>
	<div id="minute"><img src="images/minuteHand.png" /></div>
	<div id="second"><img src="images/secondHand.png" /></div>
</div>

#clock {
position: relative;
width: 378px;
height: 378px;
background-image: url('../images/clockFace.png');
left: 50%;
margin: 5em 0 0 -189px;
}

#clock div {
position: absolute;
}

The magic that rotates the clock’s hands comes via two WebKit specific CSS properties, -webkit-transition (documentation) and -webkit-transform (documentation). The transform property can alter the appearance of an element via a two dimensional transformation, for instance: scaling, rotating and skewing a DIV element. In this case it is used to rotate the clock hands to the correct angles; the CSS below puts the hour hand at 3 o’clock:

#clock img[src*='hour'] {
-webkit-transform: rotate(90deg);
}

The transition property creates an animation of a specified property between two values when triggered, for instance fading the opacity on a DIV element from 1 to 0 — triggered using the :hover pseudo class. Transition duration and the transition timing function (e.g. linear) should also be set, amongst other optional properties. In this example the transition is from one transformation angle to another with durations that match the appropriate clock hand, so the second hand takes 60 seconds to complete a 360 degree rotation. The transition is triggered using the :target pseudo element — if the URI contains the ‘clock’ fragment then the time piece shall start ticking.

#clock img[src*='second'] {
/* -webkit-transition: property duration timing-function */
-webkit-transition: -webkit-transform 60s linear;
}

#clock:target img[src*='second'] {
-webkit-transform: rotate(360deg);
}

The above transition lasts only one rotation but by altering the duration length and degree of rotation in accordance the second hand can keep on going (e.g. 600 seconds and 3600 degrees rotation gives a battery life of 10 minutes), a fairly safe assumption that users will not stay on the page for too long.

#clock img[src*='second'] {
-webkit-transition: -webkit-transform 600000s linear;
}

#clock:target img[src*='second'] {
-webkit-transform: rotate(3600000deg);
}

#clock img[src*='minute'] {
-webkit-transition: -webkit-transform 360000s linear;
}

#clock:target img[src*='minute'] {
-webkit-transform: rotate(36000deg);
}

Grab the current time

Although the animation works beautifully, CSS alone is not capable of obtaining the current time. To start the clock at the correct time a dynamic transformation needs to be applied to the clock hand containers, this is easiest done with inline styles and can be set in any number of ways by the backend when the page loads, thereby eradicating any need for JavaScript.

Alternatively, if you’ve no objections to using JavaScript, I’ve created a small startClock() function to do the job (albeit using Prototype 1.6.0.3 for my own convenience):

function startClock() {
	var angle = 360/60;
	var date = new Date();
	var hour = date.getHours();
	if(hour > 12) {
		hour = hour - 12;
	}
	var minute = date.getMinutes();
	var second = date.getSeconds();
	var hourAngle = (360/12)*hour + (360/(12*60))*minute;
	$('minute').setStyle('-webkit-transform: rotate('+angle*minute+'deg)');
	$('second').setStyle('-webkit-transform: rotate('+angle*second+'deg)');
	$('hour').setStyle('-webkit-transform: rotate('+hourAngle+'deg)');
}

A word of warning — applying the inline style directly to the image will override the transition effects defined in the CSS file.

GA gives the ability to create your own events with a category, action, label and numerical value using the syntax:

_trackEvent(category, action, optional_label, optional_value)

Hence, on an outbound link click, by calling this JavaScript method you can trigger a tracked event in GA. An obtrusive onclick attribute on every outbound link is both cumbersome to implement and difficult to manage, it also goes against the best practices of progressive enhancement and unobtrusiveness.

The solution is to attach a click event listener to each of the outbound links on the page, and the question becomes how to do that. CSS3 comes with a couple of handy new selectors that we can use in combination with Prototype or jQuery to root out the correct links. The appropriate selectors:

E[foo^=“bar”] an E element whose “foo” attribute value begins exactly with the string “bar“
E[foo*=“bar”] an E element whose “foo” attribute value contains the substring “bar“
E:not(s) an E element that does not match simple selector s

The magic outbound link selector then becomes one of the following, depending on your needs:

/* Any link that does not contain yourdomain.com */
a:not(a[href*="yourdomain.com"])

/* Any link that does not start with yourdomain.com */
a:not(a[href^="yourdomain.com"])

/* Any link that does not start with yourdomain.com or www.yourdomain.com */
a:not(a[href^="yourdomain.com"]):not(a[href^="www.yourdomain.com"])

/* Any link that starts with http - e.g. any non relative links */
a[href^="http"]

/* Catch all - any link that starts with http but doesn't link to your domain */
a[href^="http"]:not(a[href*="yourdomain.com"])

With an array of all the outbound links at hand, adding a click listener is simple. But we do need to set up the category, action and label. I have opted to create an arbitrary “Outbound Link” category that uses the link’s text (with HTML tags stripped out) as the action and the url as the label:

Event.observe(outboundLink, 'click', function() {
        // category, action, label
        pageTracker._trackEvent('Outbound Link', outboundLink.innerHTML.replace(/(<([^>]+)>)/ig,""), outboundLink.href);
}

The complete code

Using Prototype version 1.6 the final code might look like this:

Update: As pointed out in the comments, hard coding a domain into your code isn’t the best idea, window.location.hostname is a good alternative. This may not always work if you do not want to exclude subdomains.

var domainName = "domainname.com";
// Select all outbound links
$$('a[href^="http"]:not(a[href*="'+domainName+'"])').each(function(outboundLink) {
        // Add listener to each of the links
        Event.observe(outboundLink, 'click', function() {
        // category, action, label
        pageTracker._trackEvent('Outbound Link', outboundLink.innerHTML.replace(/(<([^>]+)>)/ig,""), outboundLink.href);
        }
});

Update: I have slightly altered the content’s stack to begin with Apple’s Times font rather than Times New Roman, mainly for the superior glyphs that it offers, take for instance ‘fi’ in this post’s title. I’m attempting to research the differences between Times and Times New Roman beyond a simple comparison though internet sleuthing has not proved fruitful.

I’ve spent a short amount of time researching leading, kerning, the measure, et al to improve the legibility of the content region (e.g. The Design Cubicle). I’ve increased the CSS line-spacing and slightly upped the word-spacing to make the content area more readable. The design’s horizontal dimensions are all defined in ems, so the page scales correctly with changes in font size — always maintaining an appropriate measure in the region of 78 characters, ‘a couple of alphabets’ — a good rule of thumb for legibility. The vertical alignment in the header uses pixels to keep the desired appearance. The header image uses the text-indent text replacement technique and a transparent PNG that uses Helvetica Neue to achieve a consistent branding style across platforms.

Mark Boulton states that the leading should increase proportionately with the measure. I am tempted to create a small JavaScript project for a fluid web layout that dynamically alters the CSS line-spacing of the content based on the width of the window and hence the measure; just to see how things change. I think the first problem may be deciding the scaling factor to apply to the line-spacing.

One of the biggest caveats of creating a design that strongly relies on the beauty of fonts is the difference in Windows and Apple font rendering. Take for instance the screen capture below which compares Windows XP (Left, IE7) with OSX (Right, Firefox 3). My preference is towards Apple’s stylish approach that attempts to match print, versus Microsoft’s pixel jamming but easier to read pragmatic rendering. By using fonts as the predominant styling force on the page it is clear that in this case the Apple approach is superior. Joel on Software has a very nice article that makes a good comparison between the two.

Areas still left to develop include the right hand columns, a proper grid layout and the footer, I have put these aside until next week.

This blog has been devised as a spring board for my ideas whilst serving as a professional outlet for my skills, thoughts and collaborations. If I were to include some buzz words in this opening blurb to describe the content I’ll endeavour to put here I might include; CSS3, HTML5, Information Architecture, User Experience, Unobtrusive JavaScript, Prototype & jQuery libraries, SEO, web analytics, OOCSS, progressive enhancement, accessibility, rapid design prototyping and internet marketing.

As an exciting starting point, rather than build my own WordPress theme from scratch I have opted to use the excellent Sandbox theme — ‘beautiful on the inside’. With its hugely powerful class-generating functions Sandbox creates clean and accessible markup with a huge array of context sensitive CSS selectors, creating an ‘exceptionally extensible foundation’.

For more information on the Sandbox WordPress theme I recommend checking out the official Sandbox website hosted at plaintxt or the project home on Google Code.